[sane-devel] Autotools generated files and CVS

[Olaf Meeuwissen]

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