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

[Chris White]

-----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@g.o mailing list