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 <psm...@gnu.org> 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/ > > _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make
