[bug #58735] When rebuilding makefiles, make tries them in reverse order

[Paul D. Smith]

Update of bug #58735 (project make):

                 Summary: if depending on include, gmake does not execute
commands for out of date targets in the right order => When rebuilding
makefiles, make tries them in reverse order

    _______________________________________________________

Follow-up Comment #3:

> This wrong order causes gmake or the compiler to try to access files that
have not yet been made

Well, this will only happen if you do not declare the dependencies of your
included makefiles.

If you need to have inc2.mk built before inc1.mk can be built, then you should
specify that in the makefile:


include inc1.mk
inc1.mk : inc2.mk ; build inc1.mk using inc2.mk


If you provide dependency information in your makefile, then the order in
which makefiles are attempted to be rebuilt is irrelevant.

I have no problem inverting the order, but any makefile which relies on
ordering of goal targets, rather than explicit dependency relationships, is
brittle at best.

> Make always executes the commands for all Makefiles and other files it reads
via the include directive just before it actually tries to open the related
file for the first time. This happens, whenever a related rule exists at that
time that has already been read from a Makefile, from an included file or from
the so called built-in rules.

I'm not sure where this quoted text comes from.  It doesn't come from anything
I ever said, or anything in the GNU make manual.  GNU make has never worked
like that, and it will never work like that.

> Just to remind you, this is a bug that I reported (in a partly different
way) in 1998 already and at that time, you admitted this is a bug

Unfortunately, I do not have archives going back past 2000 available to me. 
If you can point me to such archives that would be helpful.  However, there
must have been a miscommunication.  At no time have I ever considered make's
meta-behavior here (reading all makefiles first, then rebuilding the out of
date ones) to be a bug.

> Given that the include directive is a make feature that exists longer than
gmake, I expect gmake to implement the orthognal behavior people know from
other, older implemenations.

Well, I can't speak to what Roland or Richard knew or did not know, or should
have known, about "other implementations" at the time they implemented GNU
make's current behavior back in the 1980's.  However, GNU make's current
algorithm for rebuilding out of date makefiles is well-defined and has
important advantages over the model you quote above, and those advantages are
actively being used by (many) thousands of makefiles.  Changing GNU make's
"include" to work in the way described above is completely out of the
question.

I'm sorry if an email I sent caused you to think that there was a chance that
this would happen someday: I certainly didn't intend to imply that.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58735>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/