automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fast install released already?


From: Ralf Wildenhues
Subject: Re: fast install released already?
Date: Sun, 26 Oct 2008 10:11:33 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Markus, Christopher,

* Duft Markus wrote on Wed, Oct 22, 2008 at 08:15:56AM CEST:
> > > we currently use automake 1.9.6, and it would be best if
> > > we don't have to touch any of our files (autoconf 2.59, libtool
> > 1.5.24,
> > > m4 1.4.4), is this possible?
> > 
> > That's a bit tough.  What prevents you from updating to
> >   Autoconf 2.63
> >   Automake 1.10.1
> >   Libtool 2.2.6
> >   M4 1.4.12
> > 
> > which are the current versions?
> 
> Phew... this is quite a big jump for our rather old stuff. I've seen in
> gentoo that there _are_ quite a few issues when switching to libtool 2,
> so I'd really like to stick with 1.5.* in this version of our software.
> I think there where also issues when switching autoconf, but I don't
> think too many, so maybe I'll give it a try. M4 should be ok, I guess.
> Shouldn't this be more or less compatible?

Generally, the NEWS files should list every incompatibility.
(Of course, there is a chance the NEWS files are buggy, too.  ;-)
The single item that I've seen most packages needing adjustment for is
this Automake one:

  - Per-target flags are now correctly handled in link rules.

    For instance maude_CFLAGS correctly overrides AM_CFLAGS; likewise
    for maude_LDFLAGS and AM_LDFLAGS.  Previous versions bogusly
    preferred AM_CFLAGS over maude_CFLAGS while linking, and they
    used both AM_LDFLAGS and maude_LDFLAGS on the same link command.

    The fix for compiler flags (i.e., using maude_CFLAGS instead of
    AM_CFLAGS) should not hurt any package since that is how _CFLAGS
    is expected to work (and actually works during compilation).

    However using maude_LDFLAGS "instead of" AM_LDFLAGS rather than
    "in addition to" breaks backward compatibility with older versions.
    If your package used both variables, as in

      AM_LDFLAGS = common flags
      bin_PROGRAMS = a b c
      a_LDFLAGS = more flags
      ...

    and assumed *_LDFLAGS would sum up, you should rewrite it as

      AM_LDFLAGS = common flags
      bin_PROGRAMS = a b c
      a_LDFLAGS = $(AM_LDFLAGS) more flags
      ...

    This new behavior of *_LDFLAGS is more coherent with other
    per-target variables, and the way *_LDFLAGS variables were
    considered internally.

It is also one that can be a bit tough to debug if you don't know about
it.

Hope that helps.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]