[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Guide on updating autofoo

From: Wookey
Subject: Guide on updating autofoo
Date: Tue, 12 Aug 2014 16:10:53 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

As porting work (for arm64) recently I have done a lot of fixing up
packages to run autoreconf on build as this is the only way to ensure
that their config.sub/guess and libtool files are up to date for
architectures released since the software last had it's auto* files

In general this works well, but we sometimes get breakage if the
autoconf macros in the package are particularly old and unloved. i.e
are still using a lot of now-deprecated stuff.

I have not found a good guide on best practice in updating such
files. Is there one? The lack of such is one reason people don't
update their until they are forced to, I suspect.

The list of deprecated macros in the autoconf/automake docs is very
useful, but it's a bit low-level. I'd also like to know overview info
(like 'Until version foo Automake used to run libtoolize, but now it
doesn't and autoreconf does instead, so old scripts may
mean this step is not done, but using autoreconf should do it' (which
I discovered from a random blog-post somewhere)), and especially
whether in fact some local macro is simply obsolete and pointless
because now there is a 'standard' way to find out something.

Advice on the warnings that get spat out would be good too. There is a
lot of useful into in the warnings, which is simple to implement (like
quoting things properly), but "Consider adding `-I m4' to
ACLOCAL_AMFLAGS in" may well be good advice, but I don;t
know how to action it: I don't know what the merits/demerits are so
don't know when is good/bad to add it.

The existence of the --foreign scrictness option for automake is
extremly useful (to stop the lack of 'NEWS' being fatal, for example,
but it's quite obscure. I've put that one in the debian wiki.

The 'Updating macros' section of is
where I am collecting info suitable for Debian package
maintainers. Feel free to tell me if stuff is wrong, or make other
suggestions that would be useful there.

Updating openjade is an example of such a bit of software with aged autofoo:, and this is
the sort of changes things need:;filename=openjade.debdiff;att=1;bug=748626

If anyone can tell me why (after doing the above) I now get 
 make[3]: Entering directory 
 make[3]: *** No rule to make target 'Makevars', needed by 'Makefile'.  Stop
that would be good too. has been updated from the
original source, and a Makevars.template file added but it's not getting
substituted in the right place into the resulting Makefile (and maybe Presumably there is a missing macro or an old macro
that should be removed/changed which is inhibiting this?

Hmm. I seem to have got in to specific rather there, but it
illustrates the view from the porting trenches :-) And I'm very sure
that there is room for some good 'updating your autoconf/automake
files' advice.

Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]