automake
[Top][All Lists]
Advanced

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

Re: 2nd possibly silly question: XTRA_foo_SOURCES


From: Lars J. Aas
Subject: Re: 2nd possibly silly question: XTRA_foo_SOURCES
Date: Fri, 6 Apr 2001 12:51:13 +0200
User-agent: Mutt/1.2.5i

On Fri, Apr 06, 2001 at 08:01:19AM +1000, Robert Collins wrote:
: 2) I don't understand why there is a fundamental difference between
: _PROGRAMS (allows configure substitutions both directly and indirectly
: ($(CONFGSUBSTVAR)) and _SOURCES which doesn't.
: - Working on the principle of least surprise, this fails :].

I recently got a patch applied to Automake to accept Autoconf substitutions
in macro values (*_LTLIBRARIES for instance).  The reason was that depending
on how you compiled a library, the library would get a different suffix.
If I compile a debug version of a library, I may want the library to have
"_g" or "d" at the end of the name.  The same can be said for programs too.
You won't need this functionality for source files, since you have to
preprocessor for mutating the contents depending on define settings.

I don't claim this to be the reason, and I see that you can abuse using
AC_SUBST variables in *_LTLIBRARIES to turn programs on or off, which was
not the intention of enabling that feature.

It's kind of a question on how much hand-holding we should have from
Automake.  Should Automake try to restrict what the developer can do, or
should Automake let the developer run with scissors?  A restrictive
Automake has the advantage that there will be need for less support to
developers having problems because they've tried to do something that
isn't supported in ever way (like "make dist").  I'm however in favour
of the less hand-holding approach.

  Lars J



reply via email to

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