dry-run (-n) has no effect with include file generation

2008-09-01 Thread Georg Sauthoff 
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 knows how to generate
them.

Thus the bug is: If I run 'make -n' then the commands to generate the included
files are actually run.

I am using make 3.81.

Best regards
Georg Sauthoff
-- 
Fortune : 'Real programmers don't comment their code.
   It was hard to write, it should be hard to understand.' ;)


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Order of consideration of missing include files is not documented

2008-09-01 Thread Georg Sauthoff 
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 not documented - if didn't overlook it of course.

Best regards
Georg Sauthoff
-- 
Fortune : 'Real programmers don't comment their code.
   It was hard to write, it should be hard to understand.' ;)


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Misleading missing-file-messages if included file is generated

2008-09-01 Thread Georg Sauthoff 
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 and messages of the build process.

The -include workaround is dangerous, since it hides real bugs, where
make really cannot generate needed include-files.

I am annoyed by this bug for several make versions now - currently I am
using 3.81. I noticed that now at least the manual is consistent with
this make behaviour. But it is still a bug.

Best regards
Georg Sauthoff
-- 
Fortune : 'Real programmers don't comment their code.
   It was hard to write, it should be hard to understand.' ;)


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: dry-run (-n) has no effect with include file generation

2008-09-01 Thread Martin Dorey 
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 exist and 
MAKECMDFLAGS contains n.  I agree that that is sometimes useful.

- Original Message -
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
To: bug-make@gnu.org 
Sent: Mon Sep 01 05:34:47 2008
Subject: dry-run (-n) has no effect with include file generation

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 knows how to generate
them.

Thus the bug is: If I run 'make -n' then the commands to generate the included
files are actually run.

I am using make 3.81.

Best regards
Georg Sauthoff
-- 
Fortune : 'Real programmers don't comment their code.
   It was hard to write, it should be hard to understand.' ;)


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Order of consideration of missing include files is not documented

2008-09-01 Thread Martin Dorey 
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 
Sent: Mon Sep 01 05:45:33 2008
Subject: Order of consideration of missing include files is not documented

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 not documented - if didn't overlook it of course.

Best regards
Georg Sauthoff
-- 
Fortune : 'Real programmers don't comment their code.
   It was hard to write, it should be hard to understand.' ;)


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #24164] Improper Evaluation of Multiple Target rules with Static Patterns

2008-09-01 Thread Paul D. Smith 

Update of bug #24164 (project make):

  Status:None => Not A Bug  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

The followup comments are correct and this is expected and documented
behavior; I'm closing this as "not a bug".

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: Misleading missing-file-messages if included file is generated

2008-09-01 Thread Paul Smith 
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.

https://savannah.gnu.org/bugs/?102

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make