At Fri, 06 Feb 2004 12:31:05 -0500, Greg Chicares wrote: > Samium Gromoff wrote: > > > > Make does expand implicit rules, patterns, $(eval $(call)) constructs, etc. > > > > In the end the whole thing become somewhat undeterministic as far as human > > perception goes. > > Difficult-to-understand code can be written in any language. > Writing clear code is an art. One way to deal with the problem > is to avoid constructs thought confusing. For instance, many C > programmers suggest avoiding macros. Could you not avoid > constructs that you consider likely to cause confusion? [snip] > Wouldn't such a compiler have to be as complex as 'make' itself?
I can`t say for sure, but my vague suspicion is that all of the required information is produced routinely durin the usual make runs. I.e. i tend to think that makecc could share about 90% of its code with make itself. > > I do realise that the resulting makefile will be strictly bound to the existing > > file set present in the file tree at the time of compilation -- and that is > > perfectly ok, for we still have the makefile source and can recompile. > > 'automake' may fulfill some of your requirements. At least it > seems to emit simple makefiles. I consider automake being a huge PITA which adds more problems than solves. And yeah i`ve spent enough time to reassure in that opinion. (Note that i am not opposed towards autoconf/autotools, it`s just automake) > > P.S. The initial reason i`ve got thinking in this direction is a critical make bug > > in > > the current release. This bug is fixed in the latest unstable debian make release, > > but may other distributions suffer from that. And yeah, i`ve got hit by it, because > > my code used the buggy $(eval $(call )) feature. Hence i wanted a way to have a > > larger makefile which a) is generated from the complex version b) does exactly the > > same thing c) is primitive enough that it works :-) > > Would it be easier to fix that defect, say by applying the > corrective patch you mention, than to create the proposed > new program, which might perhaps have new defects of its own? I think that this makecc thing would have many positive sides besides "just doing the thing i need"---for example the most obvious benefit is that the whole mechanism suddenly becomes much more translucent and people who debug their makefiles will surely benefit from that. Second major point is that the resulting makefile is much more portable than then original---and this could be a major benefit in some corner cases. Overall i think this gives the end user more control at zero price. And this is always good. regards, Samium Gromoff _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
