Hi,
I noticed that 'make -n' (dry run) is not always like dry, like
mentioned in the help:
-n, --just-print, --dry-run, --recon
Don't actually run any commands; just print them.
In my case I have an include statement, which include files which
aren't available at make-start-time, but make
Hi,
I noticed that if you include some files in a makefile like
include a.d b.d c.d
and make knows how to make them, then it firsts generates c.d, then b.d
and so on.
To me, at least, this reverse order of the include-file-list to generate
these files feels counter intuitive.
At least it is
Hi,
suppose that you have some include-statement in the makefile like this:
include foo.d
and make knows how to generate foo.d.
Then you get a message that foo.d is missing _and_ after that make
generates foo.d.
These warning/error-messages are very misleading and clutter up useful
warnings
It's not dry when the command in question is a recursive call to make either.
That's because, in both cases, it's more useful to more people to behave this
way by default. If you want a different behavior, you can have your including
makefile decide not to include if the included file doesn't
The order of generation of any targets that don't have dependencies is not
documented. This is deliberate because there is no defined ordering. The
targets may even be generated in parallel.
- Original Message -
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
To: bug-make@gnu.org
Update of bug #24164 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Follow-up Comment #3:
The followup comments
On Mon, 2008-09-01 at 15:39 +0200, Georg Sauthoff wrote:
suppose that you have some include-statement in the makefile like
this:
include foo.d
and make knows how to generate foo.d.
Then you get a message that foo.d is missing _and_ after that make
generates foo.d.
