%% Boris Kolpackov <[EMAIL PROTECTED]> writes: bk> "Paul D. Smith" <[EMAIL PROTECTED]> writes: id> Ok, but I am surprised you don't you see any problem (bug) with id> the current way?
>> Not really. The times where it makes any difference are very few, bk> I don't think the presence of the bug is in any way affected by bk> the number of situations it is manifested in. Also you cannot for bk> sure say how many such situations there are since not everybody is bk> using make the way you do. For what it's worth I am suffering from bk> this bug too. 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. The design is perhaps not the one you would choose or would prefer, but that does not make it a bug. >> the performance penalty that would be incurred to re-invoke make >> after each makefile was recreated could be quite large. 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. 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. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
