[cfe-dev] zapcc compiler
chisophugis at gmail.com
Tue May 26 14:08:58 PDT 2015
On Sun, May 24, 2015 at 9:41 AM, Chris Lattner <clattner at apple.com> wrote:
> On May 23, 2015, at 12:25 PM, Yaron Keren <yaron.keren at gmail.com> wrote:
> > zapcc makes distinction between two classes of source files, the
> "system" ones of which all compilation state is kept in memory and the
> "user" ones whose compilation state is removed once compiled. The
> programmer can select which are the "user" files by wildcards set in a
> configuration files. The default of user is .c .cpp .cxx .CC files but it
> could easily be all files in /home/user/yaron or whatever. It is expected
> that the system files are non-changing (such a change will not be
> recognized anyhow until server restart) while the user files are the ones
> to be modified. As an example, you could have
> llvm/lib/MC/MachObjectWriter.cpp as the "user" file so every other file
> compilation result would be kept in memory.
> This sounds like a very interesting approach, but also (as you say) very
> complex :-)
> Have you looked at the modules work in clang? It seems that building on
> that infrastructure could help simplify things. In principle you could
> load “all the modules” and then treat any specific translation unit as a
> filter over the available decls.
This is actually exactly what clang's current modules infrastructure
already does. Submodules are simply a visibility filter on top of the
loaded AST. This is e.g. what the `Hidden` bit on Decl is for:
(among other places inside clang touched by implementing it this way).
-- Sean Silva
> This is also, uhm, nontrivial, but building on properly modular headers
> could simplify things a lot.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev