Follow-up Comment #3, bug #65438 (group make):
> I doubt most users will be able to map the output they see onto the input
make reads except in simple situations. When you start having lots of include
files etc. it becomes hard to follow.
i was looking for some useful simple deterministic sorti
Follow-up Comment #3, bug #54854 (group make):
If by "a warning (or a note)" you mean something printed by GNU Make, instead
of content in the documentation (this is already described there) then no, we
can't do that, because this behavior has many uses, and is used in many
situations and in many
On Tue, 2024-02-27 at 03:22 -0500, Dennis Clarke via Bug reports and
discussion for GNU make wrote:
> *** Testing FAILED! Details:
> makeerror-4.4.1-armv7l-unknown-linux-gnueabihf-izkr.tar.gz
> *** Please report to
Apologies for the delay in replying.
When filing a bug report for failed regres
Update of bug #65383 (group make):
Status:None => Not A Bug
Open/Closed:Open => Closed
___
Follow-up Comment #2:
I'm not sure what is bei
Follow-up Comment #2, bug #65438 (group make):
I think the term "sort" isn't really correct here: from the user's point of
view they simply see the output in a different, and deterministic, but still
more or less random, order than they did before. I doubt most users will be
able to map the outpu
Follow-up Comment #9, bug #65273 (group make):
Note that the trick in John's book no longer works without warnings in the
current Git-based code:
$ ./make
Makefile:3: warning: invalid variable name ' '
Makefile:4: warning: invalid variable reference ' '
Makefile:4: [ ]
make: *** No targets. Sto
Update of bug #65510 (group make):
Status:None => Works for me
Open/Closed:Open => Closed
___
Follow-up Comment #1:
The INSTALL file is not