Paul D. Smith <[EMAIL PROTECTED]> writes: > If it is a bug then what you say is true, but I have never termed it a > bug. It was a design decision taken between two alternative > implementations, and the code is operating the way it was designed and > intended to work.
I don't believe you ever intended for out-of-date makefile to trigger failure when it could be rebuilt and succeed. It is like if a C compiler would still report errors that you've just fixed refusing to compile your code. > The design is perhaps not the one you would choose or would prefer, but > that does not make it a bug. This way we can call any bug in concept a design feature. > bk> What would be nice is to have another flavor of include that would > bk> be rebuilt sequentially without re-executing make. I.e., every > bk> time make encounters such include directive it tries to rebuild > bk> the makefile and then reads it in. > > This is also quite confusing. At no time during the current make > processing does it jump out from the middle of the parser phase and into > the rule execution phase. I never said it would be easy ;-). > Not only that but the behavior would be quite > surprising to people who are familiar with make, since no rules or > variables that were defined after the include directive could be used > during the rebuild of the included makefile. I think it is no more surprising that to find make code failing because included makefile that can be built is missing. Also I am not proposing changing current schema - I think it can be quite useful sometimes. I am suggesting addition of another include directive flavor that would be well documented along with all implications (like the ones you just mentioned). But I guess it will stay just a proposal like many others before it... -boris
signature.asc
Description: Digital signature
_______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make