Support for calling clang directly?

[evanw]

I'm trying to use precompiled headers with emscripten to speed up builds. However, it doesn't seem like there is any support for calling clang directly. One hack that almost works is to pass flags via EMMAKEN_CFLAGS, but that doesn't work when there are no input files since in that case emcc doesn't even call clang. The only way I could get it to work was to run emcc with -v and copy the correct arguments to clang (defines, header include paths, and such) from the verbose output. But this feels like a fragile hack. Is there a way to drive clang directly with all of the correct include paths and other stuff set up?

[kripken]

What flags do you need to pass for that?

In general emcc is a wrapper for clang so normally we process everything and people don't need to call clang itself. But perhaps for precompiled headers things are different than other options.

[evanw]

I'm still new to manual precompiled headers but from what I can tell, you need to prefix the header with -c and not provide the output file with -o. This generates a *.h.gch file next to the header file. You also probably need the -xc++header flag. Once the precompiled header has been generated, we are force-including it into all *.cpp files with the -include flag.

Precompiled headers made a huge difference for us. The compile time for a 35 file project went from 30 seconds to 15 seconds for a debug build.

[kripken]

hmm, i wonder if that would even work with clang when used to emit llvm ir
and not normal platform-specific executables. worth trying though. if you
can make a testcase i can try as well.

[evanw]

It seems to work fine as long as the preprocessor state is the same. Here's a test case: https://github.com/evanw/emscripten-precompiled-headers

[kripken]

Thanks for the testcase. Ok, I reduced that to a testcase for the emscripten test suite, and got it to work on incoming - I think. I don't see a way to make sure that the .gch is actually being used instead of the header... any ideas?

[evanw]

Cool! The cleanest testing method seems to be passing -Xclang -print-stats to the compiler and checking for the name of the *.h.gch file. There's lots more info at http://clang.llvm.org/docs/PCHInternals.html.

[kripken]

Thanks, added to test. Looks like it works.

[missmah]

@kripken - are you planning to add -emit-pch and -include-pch support to emscripten?

See https://clang.llvm.org/docs/PCHInternals.html for details.

[missmah]

For reference, our use-case doesn't work without using -o to set the output location for the .gch (or .pch) file.

This is the output I get trying to use the PCH with -include-pch:
dev/Build/Output/HTML5-Profile/TestCore_Plugin/stdafx.gch: Input file has an unknown suffix, don't know what to do with it!

Thanks in advance for any help!

[kripken]

The last part of other.test_precompiled_headers seems to test that, so at least what is there should work. Are you using different flags/options, what specifically is missing for your use case?

[missmah]

After some testing, what is there in other.test_precompiled_headers does indeed work, with some caveats:

1. It has issues if there happens to be a .gch or .pch file in the local directory (where it will mistakenly pick that one up instead, rather than always being forced to use the requested absolute path).

2. It would be really nice to unify syntax with Clang and be able to use -emit-pch and -include-pch, and force absolute paths to the PCH (which would fix GHC output: TypeError: Cannot read property 'tokens' #1).

[kripken]

Not sure I understand the issue in 1 - perhaps you can write out a full testcase? (Even better would be to add to the test, then when we fix it, we'll have a test already.)

For 2, we have -include-pch so if I understand correctly, we're just missing -emit-pch? That's probably easy to add.