On Tue, Apr 5, 2016 at 7:19 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 5 April 2016 at 01:02, leon zadorin wrote: >> ... but even if going by your way of reading docs and taking into >> account that point alone (i.e. only one precomp. header in a >> compilation) then the process of compiling a given precompiled header >> could still use another (even if 1) precompiled header... > > It doesn't. You can verify that with 'strace' to see which files are opened. Thanks Jonathan! Of course, strace, why didn't I think of this :) completely skipped my feeble mind. Incidentally, would you have some thoughts on why this is the case? I know nothing of the theoretical challenges in representing ASTs in precompiled headers so I'm just wondering whether this behaviour is due to just a shortage of interest/need/time in GCC development land, or whether there are some fundamental technical constrains which would impede getting this done. >From reading clang (just for comparison, etc.) http://clang.llvm.org/docs/PCHInternals.html#design-philosophy just before a section on http://clang.llvm.org/docs/PCHInternals.html#ast-file-contents ... where they say: "Precompiled headers can be chained. When you create a PCH while including an existing PCH, Clang can create the new PCH by referencing the original file and only writing the new data to the new file. " ... it would feel like something of interest to the original question, at least in terms of physical possibility of being able to achieve the thing... but I'm probably way off base there also ;) Thanks for your help once again.
