Re: automake, autoconf compiling

From: Giorgos Keramidas (keramida_at_ceid.upatras.gr)
Date: 01/14/05

  • Next message: Scott Bennett: "Re: Hyperthreading hurts 5.3?"
    Date: Fri, 14 Jan 2005 11:48:58 +0200
    To: Tom Huppi <thuppi@huppi.com>
    
    

    On 2005-01-13 20:13, Tom Huppi <thuppi@huppi.com> wrote:
    >On Thu, 13 Jan 2005, Giorgos Keramidas wrote:
    >> I use autoconf/automake and libtool daily at work[1].
    >>
    >> The programs I write have to run on at least 3 different operating
    >> systems (FreeBSD, Linux and Solaris) without the need for constant
    >> manual tweaking of the source.
    >
    > At work (former), I was responsible for code which was to *compile* on
    > 6 or 7 different platforms. I choose one (often my FreeBSD
    > workstation) upon which to execute the auto-tools and didn't bother
    > with most of the others though I kept a compatible set of these tools
    > on Linux and Solaris for convenience.

    Very well said.

    I'd only like to note that the important thing to note here is:

        'a compatible set of these tools'

    > Indeed, the whole paradigm behind these tools is that they should
    > _not_ be needed on the target platform. 'autoconf' goes to great
    > pains to generate platform independent Bourne shell configure script
    > for a very good reason!

    The compatibility problems are usually encountered long before the
    program reaches 'the target platform'. The generated Bourne shell
    scripts are indeed very platform independent. The autoconf/automake
    stuff used to write them is not though.

    > Unfortunately too many people either misunderstand the paradigm and/or
    > or mis-use the tools and I suspect that this is a good portion of the
    > reason why the FreeBSD ports infrastructure needs to play so many
    > silly games with the auto-tools.

    No, the reason the Ports go through all the hoops you see is that they
    are meant to be used by people who don't care or don't need to know the
    internals of the autotools. They just need a version that 'works good
    enough for installing port foo/bar-1.2.3'.

    One other reason is, of course, the fact that the autotools have changed
    and are constantly changing the 'canonical' way of writing their input
    files. This is both a good and bad thing, depending on the viewpoint.

    It is a good thing, because it shows that they are alive, actively
    maintained projects.

    It is a bad thing, because every time a developer tries to regenerate
    the `configure' scripts and all associated files with a mismatched
    autotools version, they are forced to either: a) install the exact same
    versions the original configure.ac scripts have been written for, or b)
    abandon the idea of using autotools altogether.

    I usually go for (a), if I have a choise. The ports people do not have
    that choise, because they need to support programs coming from various
    sources, with the minimal amount of changes to the original program
    source.

    - Giorgos

    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"


  • Next message: Scott Bennett: "Re: Hyperthreading hurts 5.3?"

    Relevant Pages

    • Re: automake, autoconf compiling
      ... scripts are indeed very platform independent. ... > reason why the FreeBSD ports infrastructure needs to play so many ... the reason the Ports go through all the hoops you see is that they ... One other reason is, of course, the fact that the autotools have changed ...
      (freebsd-newbies)
    • Re: HEADS UP: Impending autotools changes
      ... In the next few days, after extensive testing, the next major update to the autotools infrastructure will be committed to the ports tree. ... As you will see from the above, the naming conventions have been changed to be "stock", with unversioned scripts allowing the use of any version of the tools via a couple of wrapper scripts written by des@. ... The ports versions of autoconf* and automake* can now be used, not only for building other ports, but also for developing platform-independent code using this tools -- as such, the gnu-* variants will be disappearing shortly. ... For IDEs, or development in general, a new port, devel/ autotools will bring in all available versions of the autotools. ...
      (freebsd-stable)
    • Fwd: HEADS UP: Impending autotools changes
      ... In the next few days, after extensive testing, the next major update to the autotools infrastructure will be committed to the ports tree. ... As you will see from the above, the naming conventions have been changed to be "stock", with unversioned scripts allowing the use of any version of the tools via a couple of wrapper scripts written by ... The ports versions of autoconf* and automake* can now be used, not only for building other ports, but also for developing platform- independent code using this tools -- as such, the gnu-* variants will be disappearing shortly. ... For IDEs, or development in general, a new port, devel/ autotools will bring in all available versions of the autotools. ...
      (freebsd-stable)
    • Re: freebsd-questions Digest, Vol 184, Issue 3
      ... Starting again from Scratch ... Re: Starting Scripts ... Repopulating the GENERIC kernel ... script to update my ports tree ...
      (freebsd-questions)
    • Re: Primary Differences: FreeBSD/Linux
      ... > shell for scripts, ... Some do, it's in ports. ... ports tree or package tools from a console command line. ...
      (comp.unix.bsd.freebsd.misc)