Chris Bagwell <chris at cnpbagwell.com> writes: > On 1/17/2009 3:20 AM, Julien BLACHE wrote: >> Chris Bagwell<chris at cnpbagwell.com> wrote: >> >>> I've not seen this discussed in mailing list archive. Is there any past >>> discussions? >> >> We leave autotools files in CVS because: >> - it's a pain to regenerate them >> - developers don't always know autofoo >> - distributions ship broken version of the autotools routinely >> - autotools versioning issues > > Fair enough. Might as well continue on this way as long as its not > presenting problems to the group.
Although I'm personally in favour of not committing any derived files in a version control system, I do see Julien's point. If we want to keep committing derived files, however, it makes sense to establish what versions of the various autotools shall be used when checking such stuff in. Not doing so will make for a lot of big commits. See also, http://www.gnu.org/software/gettext/manual/html_node/Files-under-CVS.html#Files-under-CVS. As we also discussed maintaining our changes to ltmain.sh as a patch, initial checkouts need to be bootstrapped anyway, so that patch gets applied *before* you `./configure`. If we will require a bootstrap anyway, we might as well put the autofoo stuff in there too. Once working with an autotooled build system, the Makefile's are pretty good about updating derived files so there is not that much autofoo one has to know. As for the amount of pain involved, I can only think of the time it takes. Julien mentions versioning issues and broken deployment but I have little experience with that. # FWIW, iscan requires autoconf >= 2.60 and automake >= 1.7. Hope this helps, -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962
