[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #58735] if depending on include, gmake does not execute commands fo
From: |
Jörg Schilling |
Subject: |
[bug #58735] if depending on include, gmake does not execute commands for out of date targets in the right order |
Date: |
Thu, 9 Jul 2020 10:02:38 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0 |
Follow-up Comment #2, bug #58735 (project make):
Thank you for confirming that gmake executes the commands for out of date
targets that result from the include directive in the inverse (which is the
wrong) order. This wrong order causes gmake or the compiler to try to access
files that have not yet been made - or causes gmake to complain they are
missing even though they already exist at the time, the error message is
displayed (see my other bug report).
***
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.
***
Unfortunately this is not how gmake works under all circumstances. For
Makefiles, this also applies to gmake, a Makefile that is not present, but may
e.g. be retrieved via SCCS is correctly retrieved by gmake before it opens
that Makefile for reading. But for files related to the include directive, you
have been describing the behavior currently implemented by gmake, which is
incorrect.
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 that would take
some time for fixing. 22 years is "some time", so when will this bug be
fixed?
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.
My general problem here is that gmake has more than a single bug that cause
problems on platforms that come with gmake installed as as "make". The
problems I see, partially result from attempts to work around the gmake
problems. Some of the problems appear in serial mode, others in parallel mode.
I currently have a workaround concept for gmake that works in serial mode, but
not in parallel mode and people are asking for parallel compilations.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?58735>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [bug #58735] if depending on include, gmake does not execute commands for out of date targets in the right order, Jörg Schilling, 2020/07/08
- [bug #58735] if depending on include, gmake does not execute commands for out of date targets in the right order, Paul D. Smith, 2020/07/08
- [bug #58735] if depending on include, gmake does not execute commands for out of date targets in the right order,
Jörg Schilling <=
- [bug #58735] When rebuilding makefiles, make tries them in reverse order, Paul D. Smith, 2020/07/09
- [bug #58735] When rebuilding makefiles, make tries them in reverse order, Jörg Schilling, 2020/07/10
- [bug #58735] When rebuilding makefiles, make tries them in reverse order, Paul D. Smith, 2020/07/10
- [bug #58735] When rebuilding makefiles, make tries them in reverse order, Paul D. Smith, 2020/07/10
- [bug #58735] When rebuilding makefiles, make tries them in reverse order, Paul D. Smith, 2020/07/19
- [bug #58735] When rebuilding makefiles, make tries them in reverse order, Paul D. Smith, 2020/07/19