[cfe-dev] Separate preprocess and compile: hack or feature?

Bob Haarman via cfe-dev cfe-dev at lists.llvm.org
Thu May 11 16:36:02 PDT 2017


---- On Thu, 11 May 2017 02:05:43 -0700 Boris Kolpackov via cfe-dev <cfe-dev at lists.llvm.org> wrote ----



Also, has anyone seen/heard of any real-world issues with compiling

preprocessed source code?






I think the short version of my answer is: There are pitfalls, but it may work well enough for your purposes. You may want to give your users the option to combine the preprocess and compile into a single step.


In theory, having separate preprocess and compile steps should work. A preprocessed C file is just like a non-preprocessed C file that happens not to use any preprocessor features. The C preprocessor is also used for other purposes than preprocessing C code. For example, on Unix-like systems, it is not uncommon to run assembly programs through the C preprocessor. So there is reason to believe that the C preprocessor will continue to be available to run separate from the C compiler, and that the C compiler will continue to grok files that come out of the C preprocessor. Similarly for C++.

Others have already pointed out some cases where things aren't quite that clean. I would like to add that, in my short experience working on Warp, I found that there is a lot of interdependency between the preprocessor and the compiler and the flags that are being passed to the compiler. For example, compilers like to define version macros and sometimes feature-test macros. Other macros end up being defined based on flags passed to the compiler. For example passing -mavx to gcc causes __AVX__ to be defined. So if you want to separate the preprocess step from the compile step, you have to make sure that everything that affects the preprocessor output matches between the preprocessor invocation and the compiler invocation.

Bob



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170511/33b2c29b/attachment.html>


More information about the cfe-dev mailing list