[sane-devel] Autotools generated files and CVS

Olaf Meeuwissen olaf.meeuwissen at avasys.jp
Tue Jan 20 00:53:49 UTC 2009


Julien BLACHE <jb at jblache.org> writes:

> Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
>
> Hi,
>
>> Not doing so will make for a lot of big commits.
>
> And? What's the point? As long as the build system updates are
> self-contained and not mixed with other changes in the tree, we
> couldn't care less.

My full point was:

  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.

I was referring to the pile of changes that result from committing
Makefile.in's, configure, aclocal.m4, etc that are solely caused by
the use of other versions of the autotools than those in the last
commit.

I have no problem with keeping the derived files in CVS (or git) if
that's what people prefer.  It's just that I don't.  It creates (at
times very) verbose noise in the diffs that I actively need to ignore.

>> 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.
>
> There's nothing preventing us from adding the patching within
> configure. It's a hack, but then the whole "let's use our own libtool"
> is a hack too.

Acknowledged.  It may even be a better approach as several Linux
distributions have a habit of running autoreconf --force before that
build (and for a good reason).  Putting the "hack" in configure makes
at least sure they pick up on it.

> But that point is really moot, because patching libtool without
> knowing the libtool version that's in use and is going to get patched
> is foolish and a sure way to shoot yourself in the feet (both of them,
> with the quad damage, so you'll be glad if there's a piece of one knee
> left after that).

This can be worked around by checking ltmain.sh's version.  When an
untested version is detected configure can output a warning like it
does now when it thinks you already have the sane-backends installed.

For the source tarball shipped by the SANE project, we can easily
verify that the patch has applied successfully before it's released.

>> Once working with an autotooled build system, the Makefile's are
>> pretty good about updating derived files so there is not that much
>
> If you are speaking of the fucking maintainer mode that is on by
> default, then "pretty good" doesn't read the same in my book. This
> thing is royal pain in the ass, it's dogslow and it fails more often
> than not, leaving your tree in a broken state you cannot recover from
> without some major kicking.

Maintainer mode can be turned off.  It can even be turned off by
default if one prefers to run maintainer tools by hand.  Running these
tool by hand may require a fair bit of autofoo knowledge.

>> 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.
>
> You obviously never had to work with broken libtool versions, which is
> about every libtool version until something like 3 years ago, and even
> then, there have been some pretty broken versions after that too.

Sorry, I use Debian ;-P

> If going with automake means we have to put up with the maintainer
> mode crap and bootstrapping the build system after every pull, then
> thanks, but no thanks, I'm keeping the current one.

We can make maintainer mode an opt-in and keep bootstrapping limited
to clean checkouts.

Thanks for the rant and 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



More information about the sane-devel mailing list