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@gentoo.org mailing list
