Write Makefile with Me (ii)

Third, the command error

When the command runs out, make detects the return code for each command, and if the command returns successfully, make executes the next command, which succeeds if all the commands in the rule are successfully returned. If one of the commands in a rule fails (the command exit code is not 0), then make will terminate the execution of the current rule, which will potentially terminate the execution of all rules.

Sometimes, an error in a command does not mean that it is wrong. For example, mkdir command, we must create a directory, if the directory does not exist, then mkdir successfully executed, all right, if the directory exists, then the error. The reason we use mkdir is that we have to have such a directory, so we do not want mkdir error to terminate the operation of the rule.

To do this, ignoring the command error, we can add a minus sign "-" (after the TAB key) to the makefile command line, and mark it as successful regardless of whether the command goes wrong. Such as:

Clean

-rm-f *.O

A global approach is to add "-I" or "--ignore-errors" arguments to make, so all commands in makefile ignore the error. And if a rule is to ". IGNORE "as the target, then all the commands in this rule will ignore the error. These are different levels of ways to prevent command errors, and you can set them according to your different preferences.

There is also a "K" or "--keep-going" parameter to mention make, which means that if the command in a rule fails, then the rule is executed, but the other rules continue to execute.

Four, nesting execution make

In some large projects, we will put our different modules or different functions of the source files in different directories, we can write in each directory a makefile of the directory, which is conducive to our makefile become more concise, Instead of writing all the stuff in a makefile, it's hard to maintain our makefile, a technology that has great benefits for our modular and segmented compilation.

For example, we have a subdirectory called SubDir, which has a makefile file to indicate the compilation rules for the files in this directory. Then our makefile can write like this:

SUBSYSTEM:

CD SubDir && $ (make)

It is equivalent to:

SUBSYSTEM:

$ (make)-C subdir

Defining the $ (make) macro variable means that maybe our make requires some parameters, so defining it as a variable is more beneficial to maintenance. These two examples are all meant to go to the "subdir" directory and execute the make command.

We call this makefile "Master Makefile", and the makefile variable can be passed to the subordinate makefile (if you display the declaration), but not the variables defined in the lower makefile, unless the "-e" argument is specified.

If you want to pass variables to subordinate makefile, then you can use a declaration like this:

Export <variable ...>

If you do not want certain variables to be passed to the subordinate makefile, then you can declare:

Unexport <variable ...>

Such as:

Example one:

Export variable = value

It is equivalent to:

Variable = value

Export variable

It is equivalent to:

Export variable: = value

It is equivalent to:

Variable: = value

Export variable

Example two:

Export variable + = value

It is equivalent to:

Variable + = value

Export variable

If you want to pass all the variables, then just one export will do. There is nothing to follow, which means passing all the variables.

Note that there are two variables, one is the shell, the other is makeflags, and these two variables, whether you export or not, are always passed to the lower makefile, especially the makefiles variable, which contains the parameter information for make, if we execute the " Master Makefile "When there is a make parameter or defined in the upper makefile, then the makefiles variable will be these parameters and passed to the lower makefile, which is a system-level environment variable.