public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Chris White <chriswhite@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools
Date: Fri, 20 May 2005 02:53:44 +0900	[thread overview]
Message-ID: <428CD2A8.5040508@gentoo.org> (raw)
In-Reply-To: <20050519044425.549e1f64@snowdrop>

-----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 <sys/types.h>
            #include <sys/audioio.h>
        ],[
            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


  parent reply	other threads:[~2005-05-19 17:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19  3:44 [gentoo-dev] Unofficial Gentoo Development Guide and Autotools Ciaran McCreesh
2005-05-19  5:27 ` Donnie Berkholz
2005-05-19  5:43 ` Mike Frysinger
2005-05-19 12:48   ` Mike Frysinger
2005-05-19  5:48 ` Mike Frysinger
2005-05-19 12:06 ` Stephen Bennett
2005-05-19 17:53 ` Chris White [this message]
2005-05-19 18:59   ` Mike Frysinger
2005-05-19 19:06     ` Mike Frysinger
2005-05-19 19:47       ` Chris White
2005-05-19 20:14         ` Mike Frysinger
2005-05-20  5:06 ` Ciaran McCreesh
2005-05-20  6:06   ` Georgi Georgiev
2005-05-20  6:22     ` Ciaran McCreesh
2005-05-20  9:01       ` Georgi Georgiev
2005-05-20  9:29         ` Ciaran McCreesh
2005-05-20 10:11           ` Georgi Georgiev
2005-05-20 22:10             ` Ciaran McCreesh
2005-05-20  9:40         ` Georgi Georgiev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=428CD2A8.5040508@gentoo.org \
    --to=chriswhite@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox