Re: Need support regarding the execution order of GNU Make rules

[Basil Mathew]

Hello Christian,

Thank you for the reply. My apologies for not having mentioned the
information about the "-include" statement. To be honest, the possibility
that you described did not occur to me.

But, having said that, I have to tell you that the way we include the d
files is a bit different.

We use a kind of variant of the statement "-include $(sources_c:.c=.d)"; we
use something like "include $(GEN_FILE_D)" where the variable "GEN_FILE_D"
contains the list of available dependency(*.d) files in our build system.

This means that when we are doing a scratch build, we will not have any
dependency file in the build system and we have the warning
"D:/p/0g/0a3/512/0g0a3_0u0_512/tmp/config/manage_cfiles.mk:8: no file name
for `include'" since we do not have the "-" option in the include and the
variable "GEN_FILE_D" will be empty. But even for the scratch build, I find
that all the dependency files are generated completely, before the
compilation of any of the source file begins. I suppose this means that it
is not the "include" statement that is invoking the dependency file, but
the rule itself to create the object file. Also attached below is the
output that I get after executing the Makefile with --debug option which
shows

a) that the dependency is generated by the "%.o: %.c %.d" line
b) although I am not giving you the entire debug log, please take my word
that the log shows that the dependencies are generated for all the source
files before the compilation for any of the source file is invoked.





















































*No need to remake target
`D:/p/0g/0a3/512/0g0a3_0u0_512/tmp/config/manage_cfiles.mk
<http://manage_cfiles.mk>'.Updating goal targets....Considering target file
`all'.File `all' does not exist.Considering target file `build_c'.File
`build_c' does not exist.Considering target file `errm_dcmng1.o'.File
`errm_dcmng1.o' does not exist.Looking for an implicit rule for
`errm_dcmng1.o'.Trying pattern rule with stem `errm_dcmng1'.Trying implicit
prerequisite `errm_dcmng1.c'.Trying implicit prerequisite
`errm_dcmng1.opt_c'.Trying implicit prerequisite `errm_dcmng1.d'.Trying
implicit prerequisite `errm_dcmng1.opt_a'.Found an implicit rule for
`errm_dcmng1.o'.Considering target file `errm_dcmng1.c'.Looking for an
implicit rule for `errm_dcmng1.c'.Trying pattern rule with stem
`errm_dcmng1'. ........Considering target file `errm_dcmng1.d'.File
`errm_dcmng1.d' does not exist.Looking for an implicit rule for
`errm_dcmng1.d'.Trying pattern rule with stem `errm_dcmng1'.Trying implicit
prerequisite `errm_dcmng1.c'.Trying rule prerequisite
`D:/p/0g/0a3/512/0g0a3_0u0_512//tmp/config/PROJECT_OPTIONS/gnu_opt.opt'.Found
an implicit rule for `errm_dcmng1.d'.Pruning file
`errm_dcmng1.c'.Considering target file
`D:/p/0g/0a3/512/0g0a3_0u0_512//tmp/config/PROJECT_OPTIONS/gnu_opt.opt'.........No
need to remake target
`D:/p/0g/0a3/512/0g0a3_0u0_512//tmp/config/PROJECT_OPTIONS/gnu_opt.opt'.Finished
prerequisites of target file `errm_dcmng1.d'.Must remake target
`errm_dcmng1.d'.CreateProcess(c:\legacyapp\gnumake\V101\gecho.exe,c:/legacyapp/gnumake/V101//gecho.exe
"--> Generating dependency: errm_dcmng1.c --> errm_dcmng1.d",...)Putting
child 0x005e6be8 (errm_dcmng1.d) PID 6280848 on the chain.Commands of
`errm_dcmng1.d' are being run.Pruning file `errm_dcmng1.c'.Pruning file
`D:/p/0g/0a3/512/0g0a3_0u0_512//tmp/config/PROJECT_OPTIONS/gnu_opt.opt'...........Finished
prerequisites of target file `errm_dcmng1.o'.The prerequisites of
`errm_dcmng1.o' are being made.Pruning file `errm_dcmng1.c'.Pruning file
`D:/p/0g/0a3/512/0g0a3_0u0_512/tmp/ShadowBuild//opt/errm_dcmng1.opt_C'.Pruning
file `errm_dcmng1.d'.Pruning file
`D:/p/0g/0a3/512/0g0a3_0u0_512/tmp/ShadowBuild//opt/errm_dcmng1.opt_A'.Considering
target file `errm_fctdg_test.o'.File `errm_fctdg_test.o' does not
exist.Looking for an implicit rule for `errm_fctdg_test.o'.Trying pattern
rule with stem `errm_fctdg_test'...........*

And this continues till all the dependencies are built for all the source
files and then the actual compilation takes place.

You said "*By the way, to me or doesn't make sense to make the object file
dependent on the dependency file.*", what I understand is that if we are
using "-include $(sources_c:.c=.d)" GNU Make will create the dependent file
if it is missing and will re-execute itself to read the updated include
file. This makes sense. I agree with you.

But as I have mentioned earlier, because of the way we use the include
statement as "include $(GEN_FILE_D)", this will help us in recreating the
dependency file if some user has inadvertently deleted the dependency file.
If some one accidentally deletes the dependency file and then make some
changes in any of the included header files during a subsequent build(I do
agree that the probability of such a scenario is very less), then the
object file will not be regenerated and we will end up with the wrong
output file.

Regards
Basil


On Wed, Apr 1, 2015 at 10:14 AM, Christian Hujer <address@hidden>
wrote:

> Hi.
>
> The dependency files are gendered first most likely because they are
> included with a statement like
> -include $(sources_c:.c=.d)
>
> By the way, to me or doesn't make sense to make the object file dependent
> on the dependency file.
>
> Regards,
> Christian
>  On Apr 1, 2015 10:05 AM, "Basil Mathew" <address@hidden> wrote:
>
>> Dear Support,
>>
>> My name is Basil Mathew. I work as a support engineer, for a Windows
>> Eclipse based build platform that uses GNU Make scripts, in my
>> organization. I have been asked to take over the GNU Make script support
>> and maintenance for the future. I was going through our GNU Make scripts
>> for build with the help of the GNU Make Manual and the book “Managing
>> Projects With Gnu Make” for the last week and half. It has been difficult,
>> but I am slowly making progress.
>>
>> I have a question(not related to implementation, but more related to why
>> it
>> happens the way it happens) for which I have not been able to find a
>> suitable explanation neither in the manual nor over the internet. Would it
>> be possible for some one to have a look into this question and help me
>> out?
>> I would really appreciate the help.
>>
>> *Version Info:*
>>
>> Running "gmake -version" at the command prompt gives me this output.
>>
>> C:\>gmake -version
>> GNU Make 3.80
>> Copyright (C) 2002  Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.
>> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>> PARTICULAR PURPOSE.
>>
>> The cpp.exe version that we are using as of now is "GNU CPP version
>> egcs-2.91.57 19980901 (egcs-1.1 release) (80386, BSD syntax)"
>>
>> *Build Environment Basics:*
>>
>> In our build environment, the compilation of a C-file into the object file
>> is a 2 step process as described below. We use the GNU’s “cpp.exe” to
>> generate the dependency file and then compile the C source file using the
>> specific compiler that is configured for the project. We have 2 separate
>> make rules to get this done.
>>
>> We generate the list of object files to be created as mentioned below
>>
>> sources_c = $(filter %.c,$(GEN_FILE_C))
>> objects_c = $(sources_c:.c=.o)
>>
>> where the variable “GEN_FILE_C” will contain the list of input C source
>> files. A project usually contains more than 30 C Source files.
>>
>> The rule for compilation is defined as
>>
>> build_c: $(objects_c)
>> %.o: %.c %.d
>>     !!!!Execute the Compiler Call to create the object file
>>
>> The rule for dependency generation is defined as
>>
>> %.d: %.c
>>     !!!!Execute the cpp.exe call to generate the dependency file
>>
>> We invoke the make rule “build_c”. Also we invoke the makefile with the
>> “-j” option that takes “ENV{NUMBER_OF_PROCESSORS}” as the argument.
>>
>> *Question:*
>>
>> I find that the build works fine, no problem with the build.
>> Only problem that I have is that I cannot explain why the dependencies
>> generation phase for all the 30 or more C source files are executed first
>> completely before the compilation commands for any C-source files are
>> executed.
>> I was assuming that the dependency generation for one C-source file will
>> be
>> completed followed by the compilation commands for the particular C-source
>> file followed by the dependency generation for next C-source file and so
>> on.
>>
>> Can you please explain the reason behind this if you are aware of this?
>>
>> Thanks & Regards
>> Basil Mathew.
>> _______________________________________________
>> Help-make mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/help-make
>>
>