[llvm-commits] [llvm] r51775 - in /llvm/trunk: Makefile.rules include/llvm/Analysis/AliasAnalysis.h include/llvm/Analysis/AliasSetTracker.h include/llvm/Analysis/CallGraph.h include/llvm/Analysis/LibCallSemantics.h include/llvm/Assembly/PrintModulePass.h include/llvm/CodeGen/MachineRelocation.h include/llvm/Support/CallSite.h include/llvm/Target/TargetMachineRegistry.h include/llvm/Transforms/IPO/InlinerPass.h include/llvm/Transforms/Utils/Cloning.h include/llvm/Transforms/Utils/InlineCost.h utils/GenLibDeps.pl

[Chris Lattner]

On Jun 1, 2008, at 4:38 PM, Nathan Keynes wrote:
> On 31/05/2008, at 6:21 AM, Chris Lattner wrote:
>> On May 30, 2008, at 1:01 PM, Evan Cheng wrote:
>>
>>> Yeah, it's probably better to add a '_' after the names to avoid  
>>> name
>>> clashing. If this bothers you, I can undo the patch.
>>>
>>> Nathan, can you try a different approach?
>>
>> I think this should be reverted for now.  Nathan, is it possible to  
>> just sprinkle "#undef CS" etc in a few headers?
>
> Hi Chris,
>
>   I don't really recommend changing system definitions in publicly  
> exported header files[0] (which these are of course), but if you'd  
> prefer to do it this way, patches are below (To be combined with 1+3  
> from the previous series). In the alternative I'm happy to rename  
> them to something else (whatever the preference here is, CS_ ?  
> SomeRelevantPrefixCS?)

Hey Nathan,  sorry for the delay, I'm way behind on email.

I strongly prefer to modify these definitions: if solaris was C  
compliant, it wouldn't be exporting symbols like this outside the  
system namespace.  The problem with just changing all the LLVM code to  
avoid these names is that they will be reintroduced later.

Is there any way to turn these macros off in the header that defines  
them (e.g. with a -D flag)?

I'm not super thrilled with putting the #undef's in a bunch of random  
llvm header files.  Which header is causing these to be pulled in?   
Are these definitions pulled in by DataTypes.h?  If so, we could undef  
all of them in DataTypes.h and that would "fix" most higher-level .h  
files.

Another option would be to make a special header that undef's these,  
and make the llvm build process "-include" this header when building  
for solaris.  This would probably be the most robust way to go.

-Chris