reference for beginner on configure/make/compile/linking/etc.

Sat Jun 13 03:02:41 UTC 2009

EXCELLENT answer!!!! When I have a couple hundred hours of free time I'm gonna REALLY dig into this stuff!

----- Original Message -----
From: Giorgos Keramidas <keramida at ceid.upatras.gr>
To: Gary Gatten
Cc: freebsd-questions at freebsd.org <freebsd-questions at freebsd.org>
Sent: Fri Jun 12 20:48:29 2009
Subject: Re: reference for beginner on configure/make/compile/linking/etc.

On Thu, 11 Jun 2009 17:09:43 -0500, "Gary Gatten" <Ggatten at waddell.com> wrote:
> As you may recall from a recent post I've been trying to get nTop
> compiled and working on Solaris 10 x86.  After 40 - 60 hours (I loose
> track) I *THINK* it's actually working for the most part.
>
> Before certain people get pi$$ed off about this not being a Solaris
> list - chill for a sec!
>
> I'm just looking for some materials that can help me understand the
> whole configure/make/compile/linking/etc. stuff.  Someone that knew
> this stuff could've probably resolved my issues in a few hours.  It
> seems COMPLETELY overly complex to me - maybe cause the developer
> tries to make it as portable as possible, but with every *nix like
> things putting files wherever they want, different cc's / ld's, etc. -
> I can see where it can get hairy.
>
> Anyway, TIA for your input.  Hopefully this experience and the
> references you can point me to will help the next time I try to get
> something onto FreeBSD!

Hi Gary,

The whole exercise seems overly complex, because as Mel Flynn has
already written is *is*.

A nice illustration of all the bits and pieces you have to integrate
when using the `GNU build system' is the one at Wikipedia:

  http://en.wikipedia.org/wiki/GNU_build_system#Tools_included_in_the_GNU_build_system

Merely looking at the various parts of the picture makes the mind
boggle, but it may help you get a good idea of what the various steps of
building software with the GNU build tools entails.

Documentation for the various parts of the GNU build system is available
online at the web page of each component.  Useful starting points are:

  - The GNU autoconf homepage
    http://www.gnu.org/software/autoconf/

  - The GNU autoconf manual
    http://www.gnu.org/software/autoconf/manual/index.html

  - The GNU automake homepage
    http://www.gnu.org/software/automake/

  - The GNU automake manual
    http://www.gnu.org/software/automake/manual/index.html

  - The GNU libtool homepage
    http://www.gnu.org/software/libtool/

  - The GNU libtool manual
    http://www.gnu.org/software/libtool/manual/

Note that the online copies of the manuals refers to particular versions
of these tools.  Since the various parts of the GNU build system are
notorious for introducing new features and for often breaking backwards
compatibility, it is a good idea to read the manual version matching the
_exact_ version of these tools you have installed.

The manuals are installed in Info format as part of the installation
process of these tools, so you can commonly read the local version of
the manual by typing:

  % info '(autoconf)'
  % info '(automake)'
  % info '(libtool)'

One last thing that is useful to know is that the manuals are not always
written in the form of educational material for new users.  They are a
little like a tutorial and a lot like reference guides.  So it may take
multiple iterations to understand all the concepts described in one of
the manuals, and it usually takes multiple attempts at writing a new
project ``from scratch'' before you gain enough experience in their use
to know where to look in the manual for more help.

This is a catch-22 situation, because the manual already contains a LOT
of useful information, but you don't know that it is there, or even that
it is going to be useful, until you have already read it a few times.

After having worked with autotools-based projects for a few years, here
are a few suggestions I have:

  * Read the manuals at least twice, from cover to cover.

    Don't worry if some things seem to be written in an ancient alien
    language.  They don't make sense the first time through, but they
    tend to make more sense in the next iterations through the manuals.

    Make sure that you read the manuals at *least* twice.  The first
    time some things will not make sense.  The second time, you will
    have a general overview in your mind, and more details will fit with
    the rest of the puzzle.  Every time you re-read the manuals you are
    likely to find more useful details.  The manuals contain a HUGE
    amount of information, but it takes multiple passes to understand
    and fully appreciate all of it.

  * Read the code of projects using the GNU build tools...

    Look at what other projects are doing with the GNU build tools.  By
    reading lots and lots of code, you will be able to see how others
    have solved their program's "portability" problems; you will see
    what they did to customize, extend and adapt the GNU build tools;
    you will learn new tricks and hacks, see how others write code that
    runs on multiple operating systems, platforms, machine types, etc.

  * ... but not all the code out there is `good'.

    Understand that the complexity of a full-blown build system is big,
    and as a result many of the projects you looked at misuse or flat
    out _abuse_ the GNU build tools in horrendous ways.  That's ok, as
    long as you don't blindly copy their (bogus) style.

  * Write a few small tools of your own that use the GNU build tools.

    There is *no* *way* to experience some of the gotchas other than
    falling yourself in the same traps, and discovering for yourself how
    to solve the related problems with GNU build tools.

  * Understand that there are inherent limitations or even bugs in the
    GNU build tools.

    These limitations make some things either very difficult or
    impossible to do with the tools (i.e. it is nearly impossible to use
    automake with custom rules that descend into all ${SUBDIRS} and
    invoke a specific, locally customized target).

  * Explore alternatives.

    As Mel Flynn has written, there are quite a few other toolchains for
    constructing a build system.  CMake[1] seems to be a popular
    alternative (the KDE projects uses CMake with a certain level of
    success).  SCons[2], Apache Ant[3], and Apache Maven[4] are similar
    tools.

        [1] http://www.cmake.org/
        [2] http://www.scons.org/
        [3] http://ant.apache.org/
        [4] http://maven.apache.org/

If all the above sounds like an awful lot of work, you are right!

Build automation is a large field.  There are a few decades of active
development and a bewildering array of tools actively in use today.
There are even more tools that were useful years ago, and have either
been replaced by others, morphed into more modern toolsets, or just died
out.  It's an amusing field though, with a lot of challenging and *very*
interesting things to keep you busy, and entertained for a long time :-)

<font size="1">
<div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'>
</div>
"This email is intended to be reviewed by only the intended recipient
 and may contain information that is privileged and/or confidential.
 If you are not the intended recipient, you are hereby notified that
 any review, use, dissemination, disclosure or copying of this email
 and its attachments, if any, is strictly prohibited.  If you have
 received this email in error, please immediately notify the sender by
 return email and delete this email from your system."
</font>