%% Magnus Fromreide <[EMAIL PROTECTED]> writes:
mf> In the info maual section Phony Target it is recommended that
mf> submakes are started using a pattern where each subdir is used as
mf> a target in order to make paralelization easier but this makes it
mf> very hard to communicate to the submake what the target should be.
You can use $(MAKECMDGOALS).
mf> In the section Recursive use of `make' no reference is made to
mf> that discussion and the only case that is treated is the one where
mf> there is only a single subdirectory.
mf> Which method should be preferred here?
I don't see where they conflict?
mf> Could the documentation be clarified?
Undoubtedly. I'll look at it.
mf> On a completly different point, is there any way to make GNU make
mf> turn off the automatic rebuilding of include files
No.
mf> Additionally it would be nice if there was a shorter version of
mf> --no-print-directory -- the obvious fix would seem to be that not
mf> turn it on for recursive makes, if there is a need for it then the
mf> short option -w turns it on. By the current behaviour there is no
mf> way to specify that it should be turned off save for that long
mf> name.
I guess I don't see why this is such a big problem--you don't need it on
the command line, since the top-level make doesn't print that message
anyway, and you can add it to MAKEFLAGS in the Makefile itself so what
difference does it make how long the option is?
mf> Oh yes, if there is no file to be included but make knows how to
mf> build it then that isn't strictly an error and thus it shouldn't
mf> be reported but it still is reported,
That's because the time/place when make knows there is no file to be
included and the time/place that make knows it can rebuild it are _far_
removed from each other.
mf> will the new read.c version fix this as well?
I doubt it. The read.c change is quite trivial (don't print a message
but instead set some kind of flag); it's the change in the other places
that would be needed to print the message once make discovers that it
really _can't_ build the file which are the hard parts.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.paulandlesley.org/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
