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

[Basil Mathew]

Hello Mr. Smith,

Thank you for the reply.

This is a copy of the e-mail that I have send to Christian.

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'.*
What do you think?

Thank you and Regards
Basil

On Wed, Apr 1, 2015 at 10:43 AM, Paul Smith <address@hidden> wrote:

> On Wed, 2015-04-01 at 09:46 +0530, Basil Mathew wrote:
> > 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.
> >
> > The rule for compilation is defined as
> >
> > build_c: $(objects_c)
> > %.o: %.c %.d
> >     !!!!Execute the Compiler Call to create the object file
>
> I'm not really sure why you have the object file depend on the
> dependency (%.d) file.  That seems really strange to me.
>
> > The rule for dependency generation is defined as
> >
> > %.d: %.c
> >     !!!!Execute the cpp.exe call to generate the dependency file
> >
> > 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.
>
> I assume, although you haven't said, that you are then using "include"
> to include all the .d dependency files into your makefile, following the
> model described in the GNU make manual.
>
> The advanced autodependency paper on my site does explain this [1].  You
> can also look at my post about constructed include files [2].
>
> What happens is that the first thing make tries to do is rebuild all the
> makefiles: both the main makefile ("Makefile") and ALSO all the included
> makefiles.  In your case, you include all the .d files, and make can
> find a rule (your second rule, for dependency generation) to rebuild
> them if the .c file is newer.
>
> So, make will build all the makefiles (.d files) first.  Once it's done
> with that, make will re-invoke itself from scratch and start over.  This
> time all the .d files are up to date, so make doesn't need to build them
> and so it doesn't re-invoke itself, and then it proceeds on to build the
> rest of the "normal" (.o) targets.
>
> That's why it happens in two different steps.
>
>
>
> [1]
> http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/
> [2] http://make.mad-scientist.net/constructed-include-files/
>
>