From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sls-ce5p321.hostitnow.com ([72.9.236.50]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j4JHrI8P022602 for ; Thu, 19 May 2005 17:53:18 GMT Received: from c-67-181-38-200.hsd1.ca.comcast.net ([67.181.38.200] helo=[192.168.0.106]) by sls-ce5p321.hostitnow.com with esmtpa (Exim 4.50) id 1DYpCw-000160-Dn for gentoo-dev@lists.gentoo.org; Thu, 19 May 2005 12:53:18 -0500 Message-ID: <428CD2A8.5040508@gentoo.org> Date: Fri, 20 May 2005 02:53:44 +0900 From: Chris White User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en, ja 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools References: <20050519044425.549e1f64@snowdrop> In-Reply-To: <20050519044425.549e1f64@snowdrop> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sls-ce5p321.hostitnow.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gentoo.org X-Source: X-Source-Args: X-Source-Dir: X-Archives-Salt: 3c67cf06-d8bd-4b3f-83d3-11efd151f069 X-Archives-Hash: 0b4f610523a517dd9b4853c73ffe54db -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > It came to my attention during a recent discussion on -core that a > significant number of devs don't have a clue how autotools work and find > any kind of patching that involves tinkering with configure.ac / > Makefile.am level stuff to be very tricky. Clearly, this isn't good, > because a significant number of upstream devs don't have a clue what > they're doing either. > > I've added, improved and fixed a fair number of other things in other > sections too (some of these thanks to content I've received from other > devs and not-yet-devs), so if your favourite section had a big fat TODO > on it last time you looked it may be worth checking again. And if it > still has a big fat TODO, feel free to contribute :) Another thing I'd mention too is that one can also check configure.ac to check requirements for the package (use flags as well). I've seen one too many pages where maintainers list a small number of deps, and after reading the configure.ac file, find a ton more. Examples as follows: AM_PATH_LIBFAME(0.8.10, AC_DEFINE(HAVE_NEW_LIBFAME,1,[Define this if you have libfame 0.8.10 or above])) This tells us that we need libfame >=0.8.10 . Therefore, in our deps section, we know to have >=media-libs/libfame-0.8.10 . You can also check for things that need other support enabled. For example: AC_MSG_CHECKING(for vidix support) if test x"$check_vidix" = "xyes" -a x"$ac_cv_prog_AWK" != "xno"; then if test x"$no_x" != "xyes" -o x"$have_fb" = "xyes"; then case "$host_or_hostalias" in i?86-*-linux* | k?-*-linux* | athlon-*-linux*) enable_vidix="yes" enable_linux="yes" ;; i386-*-freebsd*) enable_vidix="yes" enable_dha_kmod="no" ;; *) enable_dha_kmod="no" enable_vidix="no" ;; esac fi fi If you don't have x or framebuffer enabled, vidix doesn't work. Sometimes, there's other ways that things are checked for besides libraries. As shown here: AC_CHECK_LIB(mng, mng_initialize, [ AC_CHECK_HEADER(libmng.h, [ have_libmng=yes MNG_LIBS="-lmng" ], AC_MSG_RESULT([*** All libmng dependent parts will be disabled ***]))], AC_MSG_RESULT([*** All libmng dependent parts will be disabled ***])) AM_CONDITIONAL(HAVE_LIBMNG, test x"$have_libmng" = "xyes") AC_SUBST(MNG_LIBS) The configure script will check for libmng.h and run off of that. You're probably going to need to patch that.. because if the script's lib checking functionality isn't lib64 friendly, you're gonna see a whole world of chaos. So basically, check stuff like that out. Sometimes however, you're going to get stuff that you can only check by header. Most of the time it's kernel/system based. For example: AC_MSG_CHECKING(for Sun audio support) have_sunaudio=no AC_TRY_COMPILE([ #include #include ],[ audio_info_t audio_info; AUDIO_INITINFO(&audio_info); ],[ have_sunaudio=yes ]) AC_MSG_RESULT($have_sunaudio) AM_CONDITIONAL(HAVE_SUNAUDIO, test x"$have_sunaudio" = "xyes") Can only check for sun audio by testing kernel headers. There's no real library. Looking out for stuff like this is a real big help to figuring out what on earth your package needs. Chris White -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCjNKoFdQwWVoAgN4RArwWAKC2l9NppEReMPWEmqd6xpAPchTC9gCgiIYN 3ezPqSvy5vJBtM3Gaeu3ZUs= =TKT3 -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list