automake
[Top][All Lists]
Advanced

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

Re: precompiled header suggestion


From: Alexandre Duret-Lutz
Subject: Re: precompiled header suggestion
Date: Fri, 03 Oct 2003 00:36:25 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)

>>> "Tom" == Tom Tromey <address@hidden> writes:

[...]

 Tom> Automake could usefully automate this.  First, when building the .gch
 Tom> file we could do automatic dependency tracking (the process of
 Tom> building this file should support the normal -M flags).

Great.

 Tom> Also, if a .gch file is listed in _SOURCES, it would be cool to build
 Tom> this file before trying to build any of the objects associated with
 Tom> the _SOURCES variable.  (This could be generalized to all .h files,
 Tom> perhaps, to let us reduce the scope of BUILT_SOURCES.)  This could be
 Tom> implemented by adding a new dependency for each .o file.

This sounds tricky.  Adding such a file as a dependency of each .o file
means that _all_ of them will be updated whenever the .ghc changes.
Sounds like a loss.

Putting the .ghc in BUILT_SOURCES automatically will not work if
the .ghc includes another BUILT_SOURCES indirectly (direct
inclusion is ok because we can issue the dependency ourself).
Maybe we can live with such a limitation?

 Tom> There would also have to be a way to disable .gch support
 Tom> for non-gcc compilers.

Also I presume some libraries will also want to install such
files?  Can they be installed?  (Is this what install-pch is
about in your libstdc++ quote?)  If so, such installation also
needs to be conditional.

[...]

 Tom> We could probably already get most of this by abusing _PROGRAMS.
 Tom> That's ugly though.

Ouch. handle_programs does a great deal of work on _SOURCES
variables: looking for languages, rewriting sources into
objects, etc.  It also supports things like _LDADD etc.  All
these seem useless for compiled headers.

Maybe it would be simpler to introduce a new primary (I failed
to find a cunning name).  Obviously we need to support
sub-variables such as _SOURCES or _CPPFLAGS just like _PROGRAMS
does, but the logic would be much simpler than in _PROGRAMS
because there is no need to explore these variables.  (At least
I think there is no need, is this true?)
-- 
Alexandre Duret-Lutz





reply via email to

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