From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j4J5hpre030808 for ; Thu, 19 May 2005 05:43:51 GMT Received: from localhost ([127.0.0.1] helo=home.wh0rd.org) by smtp.gentoo.org with esmtp (Exim 4.43) id 1DYdp3-0002a8-Rq for gentoo-dev@lists.gentoo.org; Thu, 19 May 2005 05:43:54 +0000 Received: (qmail 6999 invoked from network); 19 May 2005 01:43:01 -0400 Received: from unknown (HELO vapier) (192.168.0.2) by 192.168.0.1 with SMTP; 19 May 2005 01:43:01 -0400 From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools Date: Thu, 19 May 2005 01:43:12 -0400 User-Agent: KMail/1.8 References: <20050519044425.549e1f64@snowdrop> In-Reply-To: <20050519044425.549e1f64@snowdrop> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505190143.12285.vapier@gentoo.org> X-Archives-Salt: fe5632fb-be00-43ea-b5d0-b601fc9cb6de X-Archives-Hash: 8c95b4582e21208ea1322b4a2ad9b888 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