Re: The sense of automake (Was: Processed: better make that 1.7.8... :-()
On Tue, 14 Oct 2003, Andreas Tille wrote:
> regarding to bug #215554 I would like to ask for my personal clarification:
> Which sens makes automake if the resulting output depends from every new
> subsubversion?
>
> I've thought that I would do the wordnet program some good if I would add
> automake stuff. Since I switched to auotmake1.7 I have continous trouble
> with subsubversion dependencies which now convinced me that I had a really
> stupid idea. Is there any reason for this trouble I could understand?
>
> If not I would revert my changes and will go back to just patching the
> brocken upstream Makefiles.
In general, Debian source packages should not need to build-depend on
automake. In theory, the author should already care to create an
original tarball with all the required things already created
(in fact, it is part of GNU standards that packages should not depend
on autoconf, automake, etc. to build).
There is of course a problem when you have to modify Makefile.am
(or any other similar file) in one of your packages and regenerate
files accordingly, and there are mainly two ways of doing this, none
of which is perfect. What you have probably done is to build-depend on
automake, and let the Makefiles do whatever needs to be done. This is
prone to error due to version mismatches, as you have already experienced.
The other way is to run automake yourself, using an automake version
which is known to work for your package, and ship the generated files
in the .diff.gz. This is closer to what the upstream author would do
to create a new tarball when he/she changes any of the Makefile.am
files. The problem with this approach is that make is usually confused
with the resulting timestamps at build time, since they are often a
mix between the original ones and the build time (because some of
those files were patched by dpkg-source), but if you add a couple of
touch commands in your debian/rules you might be able to convince make
that there is really nothing to regenerate. See the current gettext
package for an example of this. Not that I recommend this approach
over the other but you should be aware that this could be a way to
avoid a "build-depends: automake" and the problem you experienced.
Reply to: