automake/autoconf/libtool -- convince me
Joey Hess
in Debian in how I maintain my packages that use automake and autoconf.
This is distressing since one of us must be wrong, and I don't like
being gratuitously different anyway. So this is your chance to convince
me I'm wrong.
How I handle automake and autoconf now is I try to avoid touching the
unholy mess at all if I can. But as soon as I need to modify any of the
template files (configure.ac, Makefile.am, etc), I switch the package
over to build-depend on the tools, run them at build time, and clean up
all generated files at clean time. I may be moving toward always doing
this, even if I don't currently touch any template files.
A lot of people have said this is wrong, but I have never heard a
convincing argument with real examples of why this is wrong. I do have
some IMHO good reasons for doing it this way:
- I want my packages to be as useful as possible to users. This includes
letting users modify the template files if they need to and build the
package, and have the build succeed. Given the rapid pace of change of
automake, I can see this easily not happening, if I have a package
that only works with automake n, and version n is dropped from debian.
The user would then be stuck trying to update it to the current
automake.
This is eqivilant in my mind to a package that ships with
pre-processed C code, and compiles that. That's "ok", until you have
to modify the real source code and header files have changed. Crazy.
Instead, the right way to do things is to run it through the
preprocessor every time, and deal with it when it breaks. At least
you'll know then when it's broken so you can fix it.
- I refuse to manually patch autogenerated files. Many of the other
strategies for maintaining packages that use automake seem to end up
in requiring this sometimes.
- I prefer to keep my diffs as small as possible. I expect users and
upstream authors to read these diffs, and if they're huge the
important changes will be lost in the noise. I don't want to give
upstream authors the impression that I am forking or making huge
changes to their packages. I see 140k compressed diffs if autotools
are run in the tree once, vs 8k diffs if they're run every build
time and cleaned up after.
- This entirely avoids the problems of lurking rules in generated Makefiles
that decide to wake up on m68k and unexpectedly run the autotools
(which are not present, or fail) because of stupid timestamp issues.
Yes, I know about AM_MAINTAINER_MODE, but see above points about diffs
and autogenerated files.
While I don't know a great deal about all the portability issues the
autotools face (and indeed, don't even know much at all about automake
and libtool internals), I mainly only care about packages that work in a
single distribution. And I happen to have a lot of experience with build
systems (debhelper) that are tuned for only one distribution, and I have
some strong opinions about the right way such a build system should
work. Transparency is utterly important, so is simplicity, and
consistency, and other encies. The autotools in my opinion fail on all
counts. Of course we're stuck with them, but I prefer not to let them
inflict on my packages this broken autogenerated file thing, that they
drag in only for semi-obsolete reasons of portability (ie, the worry
that some unix system somewhere does not have autoconf on it) that don't
apply to Debian at all.
I've seen many statements from people who presumably know the autotools
cold that what I'm doing is flat out wrong, but they never back them up.
So if you want to convince me please keep my reasons in mind and back up
your statements with real explanations. Thanks.
--
see shy jo
Andreas Metzler
[invoking autoconf/automake... at build time instead of shipping the
results in the diff]
Quoting autotools-dev/README.Debian.gz
| And it wastes CPU time in auto-builders, too. Do recall that some
| architectures are very slow (m68k, for example), and that any wastage
| of auto-build time is a severe problem for Debian as a whole (it
| delays packages from moving to Debian testing, for one!).
This might not be a very strong argument but it holds.
cu andreas
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Henrique de Moraes Holschuh
> I've seen many statements from people who presumably know the autotools
> cold that what I'm doing is flat out wrong, but they never back them up.
> So if you want to convince me please keep my reasons in mind and back up
> your statements with real explanations. Thanks.
There is nothing wrong in what you're doing, other than it takes a little
more CPU than not rerunning the entire toolchain.
I've found that running the toolchain at cvs-checkout time (I use
cvs-buildpackage), is a good compromise. But to each, its own.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
James Troup
> Joey Hess <jo...@debian.org> wrote:
> [invoking autoconf/automake... at build time instead of shipping the
> results in the diff]
> Quoting autotools-dev/README.Debian.gz
> | And it wastes CPU time in auto-builders, too. Do recall that some
> | architectures are very slow (m68k, for example), and that any wastage
> | of auto-build time is a severe problem for Debian as a whole (it
> | delays packages from moving to Debian testing, for one!).
>
> This might not be a very strong argument but it holds.
No, it doesn't. It's a stupid argument[1]. I can guarantee you that
slower architectures (and I maintain buildds for one of them) will not
notice the noise of autoconf/automake in the big picture.
--
James
[1] And a recurring one; it's the same bogus argument that had policy
mandate brain-dead compile flags for a couple of years. As a
general rule do not believe anyone who starts whining about
auto-builder time. The "time" expense that matters with
auto-builders is always the human cost of processing failures; not
the build time of success builds, and esp. not some small-tiny
portion of the successful build time.
Roland Bauerschmidt
> | And it wastes CPU time in auto-builders, too. Do recall that some
> | architectures are very slow (m68k, for example), and that any wastage
> | of auto-build time is a severe problem for Debian as a whole (it
> | delays packages from moving to Debian testing, for one!).
>
> This might not be a very strong argument but it holds.
By shipping a larger diff, you're also wasting bandwidth. Come on...
--
Roland Bauerschmidt
Colin Walters
> I find myself going off in a rather different direction from most people
> in Debian in how I maintain my packages that use automake and autoconf.
> This is distressing since one of us must be wrong,
I wouldn't say that really. Each approach has advantages and
disadvantages.
> and I don't like
> being gratuitously different anyway. So this is your chance to convince
> me I'm wrong.
That being said, I do think the way I do things is better ;)
> How I handle automake and autoconf now is I try to avoid touching the
> unholy mess at all if I can.
Yeah.
> But as soon as I need to modify any of the
> template files (configure.ac, Makefile.am, etc),
Fundamentally, if you're doing this, you're hacking the upstream source,
and that likely means your changes should really be going upstream. If
you're needing to change paths or something in the Makefile.am, that
signifies that it should be a ./configure option, for example.
> I switch the package
> over to build-depend on the tools, run them at build time, and clean up
> all generated files at clean time.
My personal approach is to never Build-Depend on the autotools, and make
my upstreams use AM_MAINTAINER_MODE. Then, when I want to patch the
upstream Makefile.am, I copy the old one to Makefile.am.old, and the
current Makefile.in to Makefile.in.old, hack the .am, run automake, then
get diffs between both the .am{.old,} and .in{.old,}, and stick those in
debian/patches. By using AM_MAINTAINER_MODE I'm assured that patching
these files won't cause timestamp issues.
> I may be moving towards always doing this, even if I don't currently
> touch any template files.
Now *this* is evil. You're going to be making your builds a lot less
predictable and reliable for no good reason.
> A lot of people have said this is wrong, but I have never heard a
> convincing argument with real examples of why this is wrong.
I wouldn't say your approach is wrong inherently, so much as the changes
should be going upstream.
> I do have
> some IMHO good reasons for doing it this way:
>
> - I want my packages to be as useful as possible to users. This includes
> letting users modify the template files if they need to and build the
> package, and have the build succeed.
I dunno. I personally would never use the Debian packages of something
as a starting point for hacking the upstream source. People shouldn't
expect it to work in general.
> Given the rapid pace of change of
> automake, I can see this easily not happening, if I have a package
> that only works with automake n, and version n is dropped from debian.
> The user would then be stuck trying to update it to the current
> automake.
Now that different versions of automake are parallel-installable (except
the bastard child 1.5), I think we'll be able to keep all of them around
for as long as they're useful.
> This is eqivilant in my mind to a package that ships with
> pre-processed C code, and compiles that. That's "ok", until you have
> to modify the real source code and header files have changed. Crazy.
Not quite; trying to compile pre-processed C code on a bunch of
different architectures is not likely to work. On the other hand
Makefile.in should work everywhere.
> Instead, the right way to do things is to run it through the
> preprocessor every time, and deal with it when it breaks. At least
> you'll know then when it's broken so you can fix it.
Yes; but on the other hand some of the breakage could just be spurious.
So it just wastes your time.
> - I refuse to manually patch autogenerated files. Many of the other
> strategies for maintaining packages that use automake seem to end up
> in requiring this sometimes.
I think the method of patching I outlined above solves this issue.
> - I prefer to keep my diffs as small as possible.
Yeah.
> I expect users and
> upstream authors to read these diffs, and if they're huge the
> important changes will be lost in the noise. I don't want to give
> upstream authors the impression that I am forking or making huge
> changes to their packages. I see 140k compressed diffs if autotools
> are run in the tree once, vs 8k diffs if they're run every build
> time and cleaned up after.
Again my method of patching will *tend* to produce smaller patches, but
they can be big if your upstream is using a significantly older version
of say automake1.4.
> - This entirely avoids the problems of lurking rules in generated Makefiles
> that decide to wake up on m68k and unexpectedly run the autotools
> (which are not present, or fail) because of stupid timestamp issues.
> Yes, I know about AM_MAINTAINER_MODE, but see above points about diffs
> and autogenerated files.
I think this is solved, too.
> While I don't know a great deal about all the portability issues the
> autotools face (and indeed, don't even know much at all about automake
> and libtool internals), I mainly only care about packages that work in a
> single distribution. And I happen to have a lot of experience with build
> systems (debhelper) that are tuned for only one distribution, and I have
> some strong opinions about the right way such a build system should
> work. Transparency is utterly important, so is simplicity, and
> consistency, and other encies. The autotools in my opinion fail on all
> counts.
They fail on those counts mainly because of the portability. Yeah, it
sucks, but as you say we are stuck with them.
> I've seen many statements from people who presumably know the autotools
> cold that what I'm doing is flat out wrong, but they never back them up.
> So if you want to convince me please keep my reasons in mind and back up
> your statements with real explanations.
I wouldn't claim to know the autotools cold; but I personally don't
think your approach to dealing with modifying Makefile.am/configure.ac
is flat out wrong or anything. What I *would* say is flat out wrong is
to be rerunning autoconf/automake even if you're *not* modifying
configure.ac/Makefile.am.
My approach above gives more predictable builds, but it is less
transparent and more of a pain. I think I like keeping it painful
because it reminds me I should be sending the stuff upstream :)
Jeremy T. Bouse
> Andreas Metzler <amet...@downhill.at.eu.org> writes:
>
> > Joey Hess <jo...@debian.org> wrote:
> > [invoking autoconf/automake... at build time instead of shipping the
> > results in the diff]
> > Quoting autotools-dev/README.Debian.gz
> > | And it wastes CPU time in auto-builders, too. Do recall that some
> > | architectures are very slow (m68k, for example), and that any wastage
> > | of auto-build time is a severe problem for Debian as a whole (it
> > | delays packages from moving to Debian testing, for one!).
> >
> > This might not be a very strong argument but it holds.
>
> No, it doesn't. It's a stupid argument[1]. I can guarantee you that
> slower architectures (and I maintain buildds for one of them) will not
> notice the noise of autoconf/automake in the big picture.
>
I've also had problems where packages I've already uploaded
have problems on X arch and simply updating to the latest files from
autotools and running automake & family solves the build problems... If
it's that easy to insure that it uses the current build environment
there is no reason to apply it, diff it and upload it only to do another
upload because X need'd it done with the latest build environment but
everything else has built and running it fine...
Regards,
Jeremy
Scott James Remnant
> I find myself going off in a rather different direction from most people
> in Debian in how I maintain my packages that use automake and autoconf.
> This is distressing since one of us must be wrong, and I don't like
> being gratuitously different anyway. So this is your chance to convince
> me I'm wrong.
>
> How I handle automake and autoconf now is I try to avoid touching the
> unholy mess at all if I can. But as soon as I need to modify any of the
> template files (configure.ac, Makefile.am, etc), I switch the package
> over to build-depend on the tools, run them at build time, and clean up
> all generated files at clean time. I may be moving toward always doing
> this, even if I don't currently touch any template files.
>
> A lot of people have said this is wrong, but I have never heard a
> convincing argument with real examples of why this is wrong. I do have
> some IMHO good reasons for doing it this way:
>
I don't think it's wrong, it's just another way to do it. I actually do
this for libtool itself.
You are, however, leaving yourself open to problems caused by differing
versions of the tools on your box to the build box (or user's box). At
least by including the generated files, you know that what you upload
does indeed build from source.
I've shot myself in the foot a couple of times with this problem, but
also shot myself in the foot by forgetting to update the files just as
many times when I didn't do it this way.
Scott
--
Who isn't really a role model anyway!
Mark Brown
> I had complaints related to this with aspell, so I ended up caving in
> and leaving the auto-junk in the diff.
When I've run into a similar problem in the past I ended up just giving
people the stable packaging on top of the current upstream release to
use (this was due to the introduction of debconf so a backport was
completely out of the question). That seemed to work quite well for me.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Brian May
> more difficult to backport the package to stable. If, for example, the
> package build-depends on a newer version of libtool or automake1.7, the
> package will not build on a stable system. However, if you include the
> junk in the diff and don't re-run the autotools at build time, it will
> backport nicely (barring other issues, of course).
This is currently a big problem with my backport of coreutils.
Since coreutils in my SE-Linux is obsolete, that means I can not update
debianutils, because debianutils conflicts with older versions of
coreutils due to a file being moved.
Eventually I guess either I will have to backport the latest
autoconf/automake to my archive and/or somehow patch the differences
in, but it would be much easier if this had already been done my the
maintainer.
(of course, I realize this can get messy...)
--
Brian May <b...@debian.org>
Colin Walters
> I've found that running the toolchain at cvs-checkout time (I use
> cvs-buildpackage), is a good compromise. But to each, its own.
Personally, I think this is bad because unless you're actually modifying
the upstream build system, you shouldn't be rerunning the autotools.
And even then if you have changes you should be sending them upstream.
I understand the argument about not keeping Makefile.in, configure and
friends in CVS. What you should probably do instead of running the
autotools at cvs export time is use "make dist" to generate a tarball,
and use that as the .orig.tar.gz. cvs-buildpackage could have a bit of
automation to do this for you.
Personally, I gave up on keeping upstream packages in CVS and using
cvs-buildpackage; I find having separate patches in debian/patches is
cleaner and easier to manage.
Colin Watson
> Joey Hess <jo...@debian.org> wrote:
> [invoking autoconf/automake... at build time instead of shipping the
> results in the diff]
> Quoting autotools-dev/README.Debian.gz
> | And it wastes CPU time in auto-builders, too. Do recall that some
> | architectures are very slow (m68k, for example), and that any wastage
> | of auto-build time is a severe problem for Debian as a whole (it
> | delays packages from moving to Debian testing, for one!).
>
> This might not be a very strong argument but it holds.
I'm not sure I've ever really believed this argument. Every time it's
made I seem to recall buildd maintainers standing up and saying "no,
there's not a shortage of buildd time, there's a shortage of human
time".
--
Colin Watson [cjwa...@flatline.org.uk]
Joey Hess
> - I prefer to keep my diffs as small as possible. I expect users and
> upstream authors to read these diffs, and if they're huge the
> important changes will be lost in the noise. I don't want to give
> upstream authors the impression that I am forking or making huge
> changes to their packages. I see 140k compressed diffs if autotools
> are run in the tree once, vs 8k diffs if they're run every build
> time and cleaned up after.
>
> - This entirely avoids the problems of lurking rules in generated Makefiles
> that decide to wake up on m68k and unexpectedly run the autotools
> (which are not present, or fail) because of stupid timestamp issues.
> Yes, I know about AM_MAINTAINER_MODE, but see above points about diffs
> and autogenerated files.
I forgot to mention in here that it also avoids entirely the problems of
keeping config.sub and config.guess up-to-date.
--
see shy jo
Joey Hess
> I've also had problems where packages I've already uploaded
> have problems on X arch and simply updating to the latest files from
> autotools and running automake & family solves the build problems...
Right, config.sub and config.guess are the canoical example. Any
estimates on how many man-weeks of porter time has been wasted filing
bug reports on those?
Really, I'm sure the autobuilders spend even more time running
configure, and nobody has even seen the need to come up with a
system-level configure cache for them.
--
see shy jo
Joey Hess
> > But as soon as I need to modify any of the
> > template files (configure.ac, Makefile.am, etc),
>
> Fundamentally, if you're doing this, you're hacking the upstream source,
> and that likely means your changes should really be going upstream. If
> you're needing to change paths or something in the Makefile.am, that
> signifies that it should be a ./configure option, for example.
Some of the changes I've had to make are fairly debian-specific.
Building rpm with all libs shared, or making aalib-config not pull in
gpm, so it can work on hurd. I'm sure I could pass a lot of this
upstream, and in the main I do -- I've passed tons of aalib and rpm
fixes upstream. Problem is you always end up in the situation where
something just broke, and you have to fix it now, not when upstream gets
around to it.
> My personal approach is to never Build-Depend on the autotools, and make
> my upstreams use AM_MAINTAINER_MODE. Then, when I want to patch the
> upstream Makefile.am, I copy the old one to Makefile.am.old, and the
> current Makefile.in to Makefile.in.old, hack the .am, run automake, then
> get diffs between both the .am{.old,} and .in{.old,}, and stick those in
> debian/patches. By using AM_MAINTAINER_MODE I'm assured that patching
> these files won't cause timestamp issues.
This will often yeild big patches (on the order on 140k compressed, for
some of my packages) as you noted later on, and it's a little bit too
grubby for me. It's only one step from having patches to automatically
generated files lying around to editing them. I've seen it happen.
I also don't think it would live well with revision control.
> > I may be moving towards always doing this, even if I don't currently
> > touch any template files.
>
> Now *this* is evil. You're going to be making your builds a lot less
> predictable and reliable for no good reason.
I'm thinking about doing it just because I want this:
> > - I want my packages to be as useful as possible to users. This includes
> > letting users modify the template files if they need to and build the
> > package, and have the build succeed.
>
> I dunno. I personally would never use the Debian packages of something
> as a starting point for hacking the upstream source. People shouldn't
> expect it to work in general.
Hmm, it depends what level you're hacking on. If you want to give a
kernel patch to linus, you should work from the linux kernel. If you
want to build the debian kernel with a tweak or two, you should use the
debian kernel source. We have many users who compile packages with
different configure flags, and it's just a short hop from there to
needing to fix some issue in the configure.ac.
> > Given the rapid pace of change of
> > automake, I can see this easily not happening, if I have a package
> > that only works with automake n, and version n is dropped from debian.
> > The user would then be stuck trying to update it to the current
> > automake.
>
> Now that different versions of automake are parallel-installable (except
> the bastard child 1.5), I think we'll be able to keep all of them around
> for as long as they're useful.
How do we know when they stop being useful? It's not as you can use
build deps to track this for most packages.
> > Instead, the right way to do things is to run it through the
> > preprocessor every time, and deal with it when it breaks. At least
> > you'll know then when it's broken so you can fix it.
>
> Yes; but on the other hand some of the breakage could just be spurious.
> So it just wastes your time.
Sure, but in practice, only rpm has wasted my time, and its use of
autotools is gross, and needs extensive hacking for debian. It hasn't
been much of a problem so far for other packages.
--
see shy jo
Henrique de Moraes Holschuh
> keeping config.sub and config.guess up-to-date.
IF you are updating them indirectly, yes. Otherwise, config.sub will bite
you sooner or later.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Joey Hess
> > I forgot to mention in here that it also avoids entirely the problems of
> > keeping config.sub and config.guess up-to-date.
>
> IF you are updating them indirectly, yes. Otherwise, config.sub will bite
> you sooner or later.
They're updated (symlinked) by aclocal, which runs at build time in my
Colin Walters
> Jeremy T. Bouse wrote:
> > I've also had problems where packages I've already uploaded
> > have problems on X arch and simply updating to the latest files from
> > autotools and running automake & family solves the build problems...
>
> Right, config.sub and config.guess are the canoical example. Any
> estimates on how many man-weeks of porter time has been wasted filing
> bug reports on those?
One problem with automatically updating config.{sub,guess} by running
the autotools like you suggest is that it will (as James Troup points
out in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=195531) hide
problems. If config.{sub,guess} are outdated, upstream should be
prodded.
But that doesn't mean that we can't temporarily update it for Debian, as
long as we still get the lintian warning about outdated versions, which
will hopefully remind the Debian maintainer to prod upstream. This is
implemented in cdbs.
Colin Walters
> Some of the changes I've had to make are fairly debian-specific.
> Building rpm with all libs shared,
Seems to me that upstream should have a --enable-all-shared or
something.
> or making aalib-config not pull in
> gpm,
--disable-gpm ?
> so it can work on hurd. I'm sure I could pass a lot of this
> upstream, and in the main I do -- I've passed tons of aalib and rpm
> fixes upstream. Problem is you always end up in the situation where
> something just broke, and you have to fix it now, not when upstream gets
> around to it.
Sure; as a temporary situation it might be reasonable to Build-Depend on
the autotools. But in the long term I don't think it's right.
> This will often yeild big patches (on the order on 140k compressed, for
> some of my packages) as you noted later on,
Only again if upstream's automake is much older. If that's the case
anyways you probably want them to be updating it.
> and it's a little bit too
> grubby for me. It's only one step from having patches to automatically
> generated files lying around to editing them. I've seen it happen.
Yep. It's an unpleasant temporary situation until the stuff goes
upstream.
> I also don't think it would live well with revision control.
Dunno, just make the patches binary.
> > Now *this* is evil. You're going to be making your builds a lot less
> > predictable and reliable for no good reason.
>
> I'm thinking about doing it just because I want this:
I think that's bad, for reasons described earlier and below.
> > > - I want my packages to be as useful as possible to users. This includes
> > > letting users modify the template files if they need to and build the
> > > package, and have the build succeed.
> >
> > I dunno. I personally would never use the Debian packages of something
> > as a starting point for hacking the upstream source. People shouldn't
> > expect it to work in general.
>
> Hmm, it depends what level you're hacking on. If you want to give a
> kernel patch to linus, you should work from the linux kernel. If you
> want to build the debian kernel with a tweak or two, you should use the
> debian kernel source.
That's entirely different, because linux doesn't the use autotools.
> We have many users who compile packages with
> different configure flags, and it's just a short hop from there to
> needing to fix some issue in the configure.ac.
I very much disagree with "short hop". If they need to be hacking the
configure.ac, they'll probably need to be hacking other things too in
the upstream source, and who knows what other kinds of tools they'll
need, like docbook, gob, etc.
Your job as a Debian packager should primarily be to make the Debian
package build well. I think the real bug in your scenario is that we
don't have a standardized infrastructure for adding configure flags.
This is something that is being addressed by cdbs.
> How do we know when they stop being useful? It's not as you can use
> build deps to track this for most packages.
We'll just keep them around for say a decade or two. Given the rate of
growth of the Debian archive relative to the number of incompatible
upstream automake releases and their sizes, I think the extra space will
be like much less than statistical noise.
> Sure, but in practice, only rpm has wasted my time, and its use of
> autotools is gross, and needs extensive hacking for debian. It hasn't
> been much of a problem so far for other packages.
Ok, it sounds to me like rpm is a fairly special case, and I'm certainly
not going to fault you for not going the extra hundred tedious miles and
making all your changes into clean upstream patches. But as a general
solution, I think Build-Depending on autoconf/automake/libtool is bad.
Andreas Metzler
>> Joey Hess <jo...@debian.org> wrote:
>> [invoking autoconf/automake... at build time instead of shipping the
>> results in the diff]
>> Quoting autotools-dev/README.Debian.gz
>> | And it wastes CPU time in auto-builders, too. Do recall that some
>> | architectures are very slow (m68k, for example), and that any wastage
>> | of auto-build time is a severe problem for Debian as a whole (it
>> | delays packages from moving to Debian testing, for one!).
>>
>> This might not be a very strong argument but it holds.
> No, it doesn't. It's a stupid argument[1]. I can guarantee you that
> slower architectures (and I maintain buildds for one of them) will not
> notice the noise of autoconf/automake in the big picture.
Thanks for the correction, I'll try to get this pasragraph removed.
cu andreas
Henrique de Moraes Holschuh
> James Troup <ja...@nocrew.org> wrote:
> > Andreas Metzler <amet...@downhill.at.eu.org> writes:
>
> >> Joey Hess <jo...@debian.org> wrote:
> >> [invoking autoconf/automake... at build time instead of shipping the
> >> results in the diff]
> >> Quoting autotools-dev/README.Debian.gz
> >> | And it wastes CPU time in auto-builders, too. Do recall that some
> >> | architectures are very slow (m68k, for example), and that any wastage
> >> | of auto-build time is a severe problem for Debian as a whole (it
> >> | delays packages from moving to Debian testing, for one!).
> >>
> >> This might not be a very strong argument but it holds.
>
> > No, it doesn't. It's a stupid argument[1]. I can guarantee you that
> > slower architectures (and I maintain buildds for one of them) will not
> > notice the noise of autoconf/automake in the big picture.
>
> Thanks for the correction, I'll try to get this pasragraph removed.
Done, at least in autotools-dev.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Andreas Metzler
> On Wed, 11 Jun 2003, Andreas Metzler wrote:
> Done,
Thanks.
> at least in autotools-dev.
I've also removed it from my personal memory - you won't have to kill
me.
cu andreas
Dmitry Borodaenko
we should address it.
On Tue, Jun 10, 2003 at 02:09:24PM -0400, Joey Hess wrote:
JH> How I handle automake and autoconf now is I try to avoid touching
JH> the unholy mess at all if I can. But as soon as I need to modify
JH> any of the template files (configure.ac, Makefile.am, etc), I
JH> switch the package over to build-depend on the tools, run them at
JH> build time, and clean up all generated files at clean time. I may
JH> be moving toward always doing this, even if I don't currently touch
JH> any template files.
A case to the point: I can't build Mutt with NNTP patch from Vsevolod
Volkov (http://mutt.org.ua/), because Debian Mutt has patches that
modify Makefile.in, while Vsevolod's patch modifies Makefile.am.
Look at how Colin's major points apply to this situation.
1. Go upstream for major changes.
NNTP patch is very large piece of functionality that _needs_ to hack
upstream source, and in the same time there is no sense in going
upstream: upstream Mutt is not yet ready to accept changes of that
magnitude into itself, and that is why Marco rightfully refuses to
include this patch into the official Debian Mutt package, too. Yet, I
need this functionality now, and together with latest Debian Mutt.
2. Start hacking from upstream source, not from Debian package.
First of all, I want a Debian package, not some /usr/local installation,
and on top of that, Debian Mutt package includes a lot of nice things
(not to mention security hot-fixes) that end up in the upstream
eventually, but not soon enough.
3. Primarily, make the Debian package build well.
That is not the first priority: for end-user, it should work well; for
developer, it should not only build well, but also patch well. Patching
a package that modifies generated files sucks: try to build a Debian
Mutt with NNTP, if you don't believe that.
4. We're stuck with autotools as they are, portability breaks, etc.
If we have a problem with the toolchain, we will never get it solved by
walking around it, we can only fix it if we do it properly, and solve
all the problems that this ensues. We don't have a marketing breathing
down our necks, and isn't Debian supposed to be The Best OS?
--
Dmitry Borodaenko
Joey Hess
> First of all, thanks for bringing this up, Joey! This is a problem and
> we should address it.
Did you mean to send this to -devel? I assume so, so I am replying to
there with some context.
> On Tue, Jun 10, 2003 at 02:09:24PM -0400, Joey Hess wrote:
> JH> How I handle automake and autoconf now is I try to avoid touching
> JH> the unholy mess at all if I can. But as soon as I need to modify
> JH> any of the template files (configure.ac, Makefile.am, etc), I
> JH> switch the package over to build-depend on the tools, run them at
> JH> build time, and clean up all generated files at clean time. I may
> JH> be moving toward always doing this, even if I don't currently touch
> JH> any template files.
>
> A case to the point: I can't build Mutt with NNTP patch from Vsevolod
> Volkov (http://mutt.org.ua/), because Debian Mutt has patches that
> modify Makefile.in, while Vsevolod's patch modifies Makefile.am.
<gag> That's ugly beyond belief.
It seems to me that Colin's approach of modifying the Makefile.am and
then generating a new Makefile.in and a patch from that will kind of
work in this situation. The user would probably have to figure out how
to tell DBS, or whatever patch manager he uses not to apply the
Makefile.in patch, and then they'd be back to hoping that the
rarely-tested automake works. Of course this situation is handled fine
by my approach, with no hacking. Just patch the Makefile.am and build
and away it goes.
--
see shy jo
Joey Hess
> One problem with automatically updating config.{sub,guess} by running
> the autotools like you suggest is that it will (as James Troup points
> out in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=195531) hide
> problems. If config.{sub,guess} are outdated, upstream should be
> prodded.
>
> But that doesn't mean that we can't temporarily update it for Debian, as
> long as we still get the lintian warning about outdated versions, which
> will hopefully remind the Debian maintainer to prod upstream. This is
> implemented in cdbs.
This is also "implemented" in running autotools at build time and deleting
all the files they generate. Lintian sees the original, outdated files
and warns nicely.
--
see shy jo
Joey Hess
> I very much disagree with "short hop". If they need to be hacking the
> configure.ac, they'll probably need to be hacking other things too in
> the upstream source, and who knows what other kinds of tools they'll
> need, like docbook, gob, etc.
Dmitry's mutt example is a fine example. Just applying a third-party
patch breaks because of nasty hacks.
I don't understand your comments about docbook and gob, because of course,
if my upstream source has xml docs, I will already be build-depending on
whatever is needed to build them. Same with generated GUI stuff although I
don't have any of that.
--
see shy jo
Mark Brown
> I don't understand your comments about docbook and gob, because of course,
> if my upstream source has xml docs, I will already be build-depending on
> whatever is needed to build them. Same with generated GUI stuff although I
> don't have any of that.
Lots of upstreams ship the generated files for things like that, trying
to reduce the install reqirements to the bare minimum. This puts the
tools required into the same category as the auto* tools - needed if
you're going to make extensive changes but not required for a simple
install.
Colin Walters
> Colin Walters wrote:
> > I very much disagree with "short hop". If they need to be hacking the
> > configure.ac, they'll probably need to be hacking other things too in
> > the upstream source, and who knows what other kinds of tools they'll
> > need, like docbook, gob, etc.
>
> Dmitry's mutt example is a fine example. Just applying a third-party
> patch breaks because of nasty hacks.
Sure, but applying patches isn't always going to just work even if you
add the Build-Depends on the autotools. If this patch is really popular
than maybe Marco could put it in the package and make sure it works, but
only have it be applied if some variable is set in debian/rules or
something.
> I don't understand your comments about docbook and gob, because of course,
> if my upstream source has xml docs, I will already be build-depending on
> whatever is needed to build them. Same with generated GUI stuff although I
> don't have any of that.
Yeah, bad examples. glade is probably a better example.