[Top][All Lists]
[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