OoO Pendant le temps de midi du jeudi 16 septembre 2010, vers 12:28, Enrico Weigelt <weig...@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)
pgpM0Fy62RtPn.pgp
Description: PGP signature