Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Michael Poole]
>> On top of the default automake behavior being horribly broken, does
>> that make usual revision control practices horribly broken?
>
> It really bothers me to hear people claim as a best practice that you
> should never recompile configure.ac or Makefile.am except under
> controlled conditions. To me it is a very important philosophical
> point that Debian be self-hosting. That means packages should build
> without error from source, not just from intermediate text files like
> 'y.tab.c', 'configure', or 'Makefile.in' which, while arch-independent,
> are not particularly human-editable, and certainly not source code in
> the GPL sense.
>
> Using a provided 'configure' binary instead of building from source has
> the same problem as using any other provided binary rather than
> building from source. It clearly expresses a lack of confidence that
> the system _is_ in fact self-hosting. It tells our users, "we will
> give you all the source code, but you'd better not modify that one
> configure.in source file, because we do not dare trust our tools to
> build it correctly."
>
> So yeah, I advocate always building packages from source, and if
> autoconf someday comes up with an incompatibility that causes a FTBFS
> somewhere, let that be reported and fixed. Not just worked around by
> trying to avoid running autoconf.
The big problem is that those autogenerated build scripts will be non
deterministic on the buildd network and on users system. Depending on
the installed packages (automake/autoconf versions) you get different
results and often failures. :(
It is one thing to generate binaries from source and another to
generate the build scripts used to build those binaries.
As Debian maintainer you should always test generating the build
scripts (use maintainerclean) but for users and buildds it is better
to keep the known working results for the build scripts.
I advocate to read /usr/share/doc/autotools-dev/README.Debian.gz and
to use the config.guess and config.sub suplied by that package but
otherwise not to run the auto* tools during builds. That has just
proven to be most reliable.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
