help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Basil Mathew
Subject: Re: Need support regarding the execution order of GNU Make rules
Date: Thu, 2 Apr 2015 13:37:46 +0530

On Thu, Apr 2, 2015 at 10:38 AM, Paul Smith <address@hidden> wrote:

> On Wed, 2015-04-01 at 17:37 +0530, Basil Mathew wrote:
> > This is a copy of the e-mail that I have send to Christian.
>
> You don't need to forward another copy: that's the beauty of a mailing
> list: everyone gets all the mail :).
>
>
That's also why when sending to mailing lists, especially archived lists
> like this, we prefer people to use "inline replies" rather than
> "top-posting replies"; this is an example of an inline reply where I
> quote only the parts of your message I want to reply to and I reply
> directly after the parts I want to address, rather than including the
> entire message and adding comments to the top.
>

Thank you for the information, Hope, this time,  I am doing it right.


> > 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.
>
> OK, that's critical information, thanks for providing it.
>
> > 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
>
> That's not exactly true.  What appears to be happening is that your
> target wants to build an object file foo.o and matches this pattern.  It
> then needs to try to build the prerequisites, one of which is the foo.d
> file before it can build the object file, so it uses the other pattern
> rule "%.d : %.c" to build the foo.d file.
>

My mistake. I meant the same, but my e-mail was not clear enough. Thank you
for the clarification.

>
> > 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.
>
> It looks to me like you are building with parallel make (-j), from debug
> output like this:
>

Yes, you are right. I have mentioned this in my first post.


>
> > Finished prerequisites of target file `errm_dcmng1.o'.
> > The prerequisites of `errm_dcmng1.o' are being made.
> > ...
> > Considering target file `errm_fctdg_test.o'.
>
> which shows that make is skipping building errm_dcmng1.o because one of
> its prerequisites (in this case the .d file) is being built.  After
> this, make will go on and find something else to build, which will
> probably be another .d file.  This can make it seem like the .d files
> are being built first.
>

I had the same notion, but what I could not understand was that there are
some
projects in our organization that contain some 3000 C source files, and the
dependency
generation phase itself takes more than 10 minutes with cpp.exe, but every
time, I see
that the compilation phase is invoked only after all the dependencies are
computed, hence
the post. From your feedback, I am satisfied with the notion.


>
> If you run your build linearly, without the -j flag, you should see it
> behave as you expect.
>
>
You are right.
I found this when I was executing some test Make scripts to validate my
above post without
using the -j flag. I am assuming that if we don't explicitly specify the -j
flag, make will execute
a linear build(similar to -j = 1)


> I'm not sure what difference it makes, though, whether the .d files are
> created first as long as the right files are built in the right order
> overall.
>
>
I did not see any issue with the build, had posted this to clarify the
behavior.

Thank you all for the wonderful support


reply via email to

[Prev in Thread] Current Thread [Next in Thread]