bug-m4
[Top][All Lists]
Advanced

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

Re: changing compiler flags at configure time


From: Ralf Wildenhues
Subject: Re: changing compiler flags at configure time
Date: Mon, 12 Jun 2006 15:22:43 +0200
User-agent: Mutt/1.5.11

Hi Eric,

* Eric Blake wrote on Mon, Jun 12, 2006 at 03:12:33PM CEST:
> 
> CVS head of m4 currently has a macro, ltdl/m4/debug.m4, that attempts to
> alter compile-time flags according to whether --enable-debug is passed to
> ./configure.  However, it uses AC_DISABLE_SHARED and AC_ENABLE_SHARED
> inside a shell if-then-else to enforce this decision, and autoupdate
> reports that both macors are obsolete and should now be done by LT_INIT.

Yes, we need to un-obsolete these two (at least), or replace them by
differently-named other macros.  Maybe LT_DISABLE_SHARED and
LT_ENABLE_SHARED.  Rationale: LT_INIT([options]) isn't flexible enough
for some users (such as M4).

> Hmm, AC_ENABLE_SHARED and its replacement of the parameter 'shared' to
> LT_INIT aren't even mentioned in libtool.texi.

TODO, too.  Patches for both gladly accepted.

> Is it safe to call LT_INIT more than once,

No, and it should explicitly flag this error.

> in order to conditionally
> change what libtool's defaults should be according to the outcome of an
> AC_ARG_ENABLE?  Or is it safe to pass a shell variable instead of a
> literal as the argument to LT_INIT?

No, that is not safe either.

> Also, m4 uses the obsolete AC_LIBTOOL_COMPILER_OPTION in one place, and
> its replacement _LT_COMPILER_OPTION in another.  Any chance that we can
> document and make this macro public, so that m4 isn't relying on
> undocumented internals of libtool?

I'm wary of doing that at the moment.  This macro is very brittle.
It checks that the compiler either does not output any warnings, or
that the warnings do not change when the tested flag is added.
Experience shows that this can easily fail with lots of compilers --
in fact, the sister macro _LT_LINKER_OPTION currently breaks the
computation of link_static_flag for some compilers because of this.

I have thought of eventually special-casing these compilers somehow,
possibly by grepping out their output, if detectable.  I'm not so
happy to do this sort of changes in a public macro.

Remember M4 uses _LT_LINKER_OPTION because that macro originated in M4.

Cheers,
Ralf




reply via email to

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