>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> 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