setting platform-specific PP macros should be exposed as a library method

[llvmbot]

Bugzilla Link	3979
Resolution	FIXED
Resolved on	Feb 22, 2010 12:49
Version	unspecified
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@efriedma-quic

Extended Description

Recently, a change was made to move platform-specific macro setup from the PP to clang-cc.cpp - InitializePredefinedMacros().

While the idea to de-couple it from the PP is nice, this poses a problem for users who are interested in writing tools that use clang as a library.

A tool should be able to initialize the PP with the default macros for his target triple without explicitly setting those macros and knowing about the specific macros. It should just call some library method in clang.

This used to be the case, as it was handled by the PP. However, it is no longer possible - since it is now done in a static method in clang-cc.cpp.

The alternative, to copy-paste a bunch of code that sets specific macros from clang-cc.cpp into one's ow app that uses clang as a library, really sucks.

[llvmbot]

In order to make my app function correctly, I had to copy InitializePreprocessor() and all the functions it calls (which are in the same file) into my application, and delete its use of the command-line specific params.

So the solution is to move InitializePreprocessor() to a file and export it in a library, as well as moving the additional defines based on command-line args to clang-cc to another function (the code that uses D_macros, U_macros, ImplicitMacroIncludes, etc.).

[llvmbot]

My perspective is that much of the functionality which is in clang-cc should move into libFrontend.

clang-cc should eventually be minimized to be a small layer which translates from the command line arguments into well formed API calls. This is also the path towards merging clang-cc into the driver, since once this is complete the driver can just make the API calls directly instead of fork()/exec().

[efriedma-quic]

Fixed by r69664, I think. (Correct me if I'm wrong.)