%% Christopher J Bottaro <[EMAIL PROTECTED]> writes: cjb> ok, now i'm confused. i'm looking at some pretty popular linux cjb> projects (KDE) and in their makefiles (generated by cjb> automake/autoconf)
That's your answer right there. Automake generates makefiles that work with the least common denominator version of make, so they can't take advantage of any of the modern features of GNU make (or any other make). If you want your makefiles to work with every version of make and every version of sh out there, no matter how ancient and crusty, then you'll have to do things similar to what you see in an automake generated makefile. Since these makefiles are generated automatically, it doesn't really matter how long and complicated they are: someone only has to write it once anyway. If you're writing your makefile by hand and don't mind requiring relatively modern tools, like GNU make and a POSIX-compliant shell, you can avoid most of the hacky stuff in autoconf/automake. In short, you shouldn't use those files as examples of "best practices" for writing makefiles. If anything at all, they're examples of "best practices" for creating maximally portable makefiles and scripts. But as you've seen, maximally portable is in no way equivalent to maximally maintainable. That is, after all, why autoconf and automake were created in the first place. cjb> the command lines of the rules are pretty big shell scripts cjb> (complete with for loops to do recursive makes). this seems to cjb> be pretty much the standard way to do things it seems. Depends on what kind of "standard" you want to adhere to. If you want makefiles that are massively portable then why write them yourself? Just use automake in the first place and save yourself a lot of aggravation. cjb> i did a search for "recursive make" and found web articles giving cjb> examples of using the shell for loop as the "correct" way of cjb> doing it. It's not the best way. At least, not for GNU make. cjb> why is what seems to be the "accepted standard" the wrong way to cjb> do it? Because I said so, and I know better :). Seriously, those methods are OK. They will work to some extent, but they all have problems. They don't obey flags like -k. They don't work well with parallel makes. Etc. If you don't care about those things, then doing it with a shell loop is fine. It will work. Just not as well. Also, doing it the better ways often requires you to make assumptions about your version of make, because many of those things can't be done in "standard" make syntax. cjb> $(RECURSIVE_TARGETS): cjb> sh recursive_targets_makefile.sh First, you're forgetting that the original shell script contained many make variables. In the original script, those variables are expanded into values _BEFORE_ the script is sent to the shell. Once you're in the shell script there's no way to get ahold of the values of those variables (unless you're going to export them--and exporting make variables is not supported by may versions of make). So you would have to pass those values on the command line of the "recursive_targets_makefile.sh" script, which already makes it less simple. Second, projects don't really want automake to go around creating lots of little helper scripts to litter their project directories. And finally, it works embedded in the makefile so why bother with an extra file? cjb> that way that huge, ugly, multiline command can be tucked away in cjb> a shell script...where you don't have to use so many ";"s and cjb> "\"s. Who cares how many ";"'s and "\"'s there are, when the whole thing is autogenerated? That's exactly why automake was created, so no one would have to care how gross these scripts are. -- ------------------------------------------------------------------------------- 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 _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
