OoO Pendant le temps de midi du jeudi 16 septembre 2010, vers 12:28,
Enrico Weigelt <weigelt@metux.de> disait :
>> About autoconf stuff:
>> - Why require autogen.sh? On a release, configure script should be
>> present. No need to rebuild it.
> No, there often *is* a need to rebuild it (actually, much of my
> QM work on dozens packages requires changing configure.in+friends).
> And you don't seriously want to patch autogenerated files, do you ? ;-o
>> Some users just don't have recent enough autotools to rebuild the
>> configure.
> They should simply install it. Similar as they need recent toolchain,
> make, pkg-config, etc, etc.
No, no, no. Users are not limited to Debian developers using Sid. Users
may try to compile on an old RHEL 2. They should absolutely not try to
rebuild configure since it is likely to not work and leave them with an
unconfigurable package. On most projects, there is not autogen/bootstrap
in the realeases for this very reason: do not confuse the user and let
him install autotools which is not mandatory at all. autogen/bootstrap
is shipped in the VCS repository because this is targeted at developer.
autotools are aimed at the end user, not the distro packager. This is
stated in the introduction to autotools. This is nice to be nice with
the distro packager but the primary target is the lambda user (which is
usually less skilled than the distro packager).
Compiling software from source is enough a pain to avoid any unecessary
dependency. No need for a recent toolchain and no need for autotools for
a software aimed at running on a lot of systems (which is what autotools
are for too).
>> - Not using AC_TRY_RUN is too strong.
> No, it's mandatory. It simply cannot crosscompile, no chance.
>> This macro has a parameter to be used when cross-compiling.
> It's inherently unreliable, by design. The developer has to specify
> some default behaviour in case of crosscompiling. And that's most
> likely wrong. If you do use that macro, you've normally relying
> on basicly assumptions. Such as the building system is equal
> (yes *equal*, not just similar) to the actual target system.
>> It is more useful to detect a problem when not cross-compiling
>> with AC_TRY_RUN than to not detect it at all.
> If you really wanna have some runtime tests, then it should be
> done separately (eg. separate script or in make test stage).
Oh sure, if there is a problem that can only be detected at runtime, I
will let the user deal with it in some "make test" that nobody runs
instead of handling the problem for him in most situations in
configure. Again, configure is targetted at the end user (which usually
does not cross-compile). It should automatically configure the software
to be in a workable state after compilation. No need to read some
README or run some additional scripts.
As upstream, I care about Debian and cross-compiling but I also should
care about people wanting to compile my software on old RHEL 2 or on
Debian Etch (an old enough platform to require some runtime test in my
case). None of those platforms have a recent enough autotools to rebuild
configure, BTW.
--
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)
Attachment:
pgpp3oAqZQKPg.pgp
Description: PGP signature