Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Mike Frysinger]

On Wednesday 18 May 2005 11:44 pm, Ciaran McCreesh wrote:
> What more would people like to see explained? Is there anything in there
> that needs changing or clarifying? Anything that's just plain wrong?
> Does it need a section on libtool and if so does someone want to explain
> to me how the heck it works? Are there good examples of ebuilds which
> make understandable changes to these things that I should be adding as
> illustrations? Do you like the picture? Feedback please.

it doesnt cover anything related to older autotools which do not have 
Makefile.am, but i think that's something we can neglect now since the number 
of projects that still just have configure.in/Makefile.in are in decline and 
in low numbers ... i'd point out that some projects (like binutils/gcc) will 
probably never be 'updated', but thankfully the people who work on those 
packages *seem* to know what they're doing

things i'd add:
- make a note at the top that it doesnt matter if the file is configure.in or 
configure.ac, autoconf will act the same ... it's currently hinted at but not 
explicitly mentioned ...
- maybe a section on aclocal and m4 files ... an advanced topic that most 
people shouldnt need to know about ...
- i believe all autotools should be executed in src_unpack() rather than 
src_compile() ... i see unpack as the 'preparation' stage for the 
'compilation' stage of things ...
- there is no 'autoconf-2.5' binary ... there are the perl scripts 
'autoconf-2.13' and 'autoconf-2.59' ...
- when talking about exporting WANT_AUTOMAKE, the usage of 'We can export 
WANT_AUTOMAKE here ...' is a little vague ... it makes it sound like we could 
export it inside the configure.ac rather than when we invoke automake
- WANT_AUTOCONF / WANT_AUTOMAKE are gentooism's that were originally taken 
from Mandrake ... i'm not sure what other distro's use an autotool wrappers, 
but it'd be nice to note this
- library checks are AC_CHECK_LIB while header checks are AC_CHECK_HEADER ...
- maybe set the 3rd parameter of AC_ARG_ENABLE to be enable_cscope=$enableval
- i would add notes under AC_ARG_ENABLE / AC_ARG_WITH that misuse of these 
macros is *very* common due to the confusing description of their 
arguments ... many people think the 3rd/4th arguments correspond with 
enable/disable when in reality they correspond with specified/not 
specified ... ive seen many packages which do:
AC_ARG_ENABLE(blah, [help output], enable_blah=yes, enable_blah=no)
- the most common evil auto check ive seen is when code just does AC_CHECK_LIB 
and then enables/disables support for that library based on the result
- add links to the autobook website (`esearch autobook` for the URL) and links 
to the autoconf/automake/m4 documentation ... i think they all have online 
html versions built off of the bundled docs
- maybe mention that every package which is built on newer autotools (it has a 
Makefile.am and Makefile.in instead of just Makefile.in) should support 
DESTDIR just fine ... if it doesnt, the fault is 99.9% of the time made by 
the package maintainer rather than autotools
- add some notes about how variables in Makefile.{am,in} of the form @VAR@ 
will be expanded if you use the m4 macro AC_SUBST(VAR)

now for long term suggestions:
- develop a reference list of m4 macros since the autobook docs are 
outdated ... have a list that tries to help people who havent worked with 
autotools before ... developer knows they want to verify a header exists or a 
library exists, but they dont know what macro to use
- add a section to cover cross-compile issues ... for example, using 
AC_TRY_RUN is bad manners, even if you do specify a somewhat 'sane' 
default ...
-mike
-- 
gentoo-dev@g.o mailing list