automake
[Top][All Lists]
Advanced

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

Re: declaring sources ...


From: Ralf Wildenhues
Subject: Re: declaring sources ...
Date: Wed, 15 Aug 2007 13:15:55 +0200
User-agent: Mutt/1.5.16 (2007-07-16)

* NightStrike wrote on Wed, Aug 15, 2007 at 12:17:45PM CEST:
> On 8/15/07, Ralf Wildenhues <address@hidden> wrote:
> > > Note all the "XXXX.cpp" files and the AM_CXXFLAGS and AM_LDFLAGS.  The cpp
> > > files vary over time and I have to refresh the list every time.  Is there
> > > anyway to declare something like *.cpp??
> >
> > No.  The limitation is intentional, because then you can have a
> > ApplicationOld.cpp in your source tree, without having it automatically
> > compiled or distributed.  Even with revision control, this is handy at
> > times.
> 
> Why is this not a toggleable option of some sort?

Because I wasn't giving the full reasoning, just one important one.
First, as a side note it would most likely be $(srcdir)/*.cpp or both
(in the case of generated sources).  As another side note you can
AC_SUBST some *_SOURCES variable, if you took care to list all possible
source files in an EXTRA_*_SOURCES variable.

Automake needs to know (a superset of) the list of source file names, in
order to be able to compute object file names, rename them if needed for
(e.g.,) per-target flags, and in that case output per-object rules.  All
this would simply not work another way.  For each possible object file,
.deps/*.Po files need to be generated at config.status time, and for
that automake also needs to know the source file names, at least the way
things currently work.

FWIW, there may still be other reasons I haven't thought of yet.

> Why force a user
> into a difficult situation that will end up having a kludgey
> workaround? (like something that auto-generates the makfile.am,
> bringing the total layers to what.. 4?  some script > makefile.am >
> makefile.in > makefile.  )

Why is that considered a kludge, by the way?  I see it as a logical way
to extend the functionality of autoconf and automake.  It's already done
by libtoolize, gettextize/autopoint, gnulib-tool, and some integrative
build environments like kdevelop.

Cheers,
Ralf




reply via email to

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