-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hrvoje Niksic wrote: > Micah Cowan <[EMAIL PROTECTED]> writes: > >> - Automated packaging and package-testing > > What packaging does this refer to exactly?
Distribution tarballs. Automake has extremely good built-in creation and testing of distribution tarballs. It'll pack 'em up, then unpack it to someplace, do a build (IIRC, from a separate location from the unpacked source), and a test (I think?), and then check various properties on the results. It's very nice! >> - Automatic support for a wide variety of configuration and build >> scenarios, such as configuring or building from a location other than >> the source directory tree, or the DESTDIR late installation-location >> variable. > > This has worked with Autoconf-enabled programs (including Wget) for > ages. Not very well, at least in the case of wget. For instance, *.gmo files end up in the source directories, rather than in separate build directories, at least at the moment. I'm sure this is easily fixed, but I suspect other issues may lurk. >> - Complicated >> >> I actually don't find this to be true. The arguments to this effect seem >> to refer to the generated Makefiles.... but you don't _edit_ those. > > I think this is the crucial point. If you really find the generated > Makefiles to be managable, both in case when you need to edit them by > hand (for whatever reason) and in the case when you need to understand > them (to tell why something went wrong or to fix a problem), then > Automake is the right choice. I find Automake-generated Makefiles to > be completely unreadable and immutable. The only ones that even come > close are the Makefiles generated by imake, and autotools were > supposed to be a step forward. They could certainly be more readable, 'tis true. But so far I've always been able to find what I was looking for, and alter the Makefile.am file appropriately to fix the issue. I won't deny that Automake is not entirely flexible (and I should have mentioned this in the cons); but so far I have not run into a situation where I really could not make Automake do what I needed. I may have sometimes needed to write an ugly rule or two, but IMO the benefits far outweigh these problems. >> In terms of actually writing the Makefile.am documents, though, in >> general it is actually much _easier_ than writing the plain Makefile >> equivalents. > > As long as what you want to do is supported by Automake, yes. Heh, yeah, see above. :) >> I obviously wouldn't be looking to make the move for our upcoming >> 1.11 release in September; but I would desire to make the move soon >> thereafter. Since this was apparently something that some people >> felt strongly about, I thought it'd be wise to broach the subject >> now, so we have plenty of time to discuss it. So, please speak up! > > I don't think you will find hard technical arguments one way or the > other; at this point the choice seems a matter of taste more than > anything else. And as always in such matters, who does the work gets > to make the call. Either way, I'll certainly support your decision. Thanks! :) I can't claim to be an Automake fanboy (or really, Autotools in general). I definitely believe it is not appropriate for all projects; but it's my (current) opinion that it is appropriate for this one. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGoUFL7M8hyUobTrERCKcCAJ97fv8UtKrPhdst6CWws70uqvE5DQCeJZoj pdn9EuXW8czWnaGvhBgPXe4= =4ofd -----END PGP SIGNATURE-----
