Some time ago I ran into problems with conflicts because the LLVM DEBUG macro
and macros defined by our internal software here. I worked around it but it
is ugly.
This just came up again today. The fundamental problem is that two pieces of
software both use the generic name "DEBUG." This is just problems waiting
to happen. We need some kind of namespace.
Would the LLVM community be open to changing DEBUG to something like
LLVM_DEBUG? I am pushing to have our code be changed in a similar way.
It's just not good design to use a generic name like DEBUG that isn't
qualified by some prefix/namespace.
-Dave
Debug.h should only be #included by .cpp files, not .h files. Are you seeing a case where you need to use both debug macros in a .cpp file?
-Chris
I just checked, and Debug.h was included in a few .h files,
which I've now fixed.
Dan
That's not the issue. We have some interface (.cpp) files that convert from
our IR to LLVM IR. Those files need to include headers from both LLVM and
our compiler components. That is where the DEBUG conflict happens.
-Dave
Do you need to use both of the debug mechanisms in the same CPP files?
-Chris
I have mixed feelings about this. I consider LLVM's debug macro to really be an internal implementation detail that shouldn't be "exported" as part of it's API. It is unfortunate that the C preprocessor is so bad at this sort of thing.
Since I think it really is a part of the LLVM internals, I don't think that mangling it with a prefix is the right way to go. This would significantly increase verbosity in the code and would be generally detrimental.
As a solution for your problem, would something like this work?
#include "llvm/Debug.h"
#define LLVM_DEBUG(X) DEBUG(X)
#undef DEBUG
#include "DavidDebug.h"
...
Or visaversa?
-Chris
>>> from our IR to LLVM IR. Those files need to include headers from both
>>> LLVM and our compiler components. That is where the DEBUG conflict
>>> happens.
>>
>> Do you need to use both of the debug mechanisms in the same CPP files?
>
> In some cases, yes.
I have mixed feelings about this. I consider LLVM's debug macro to really
be an internal implementation detail that shouldn't be "exported" as part
of it's API. It is unfortunate that the C preprocessor is so bad at this
sort of thing.
Yes, I understand your feelings here.
Since I think it really is a part of the LLVM internals, I don't think
that mangling it with a prefix is the right way to go. This would
significantly increase verbosity in the code and would be generally
detrimental.
Verbose, yes, but "generally detrimental?" That's a pretty strong statement.
As a solution for your problem, would something like this work?
#include "llvm/Debug.h"
#define LLVM_DEBUG(X) DEBUG(X)
#undef DEBUG
#include "DavidDebug.h"
...
Perhaps. I'll have to think on that.
-Dave
More specifically, this impacts the tyranical 
80 column limit we have:
DEBUG(cout << "whatever stuff here" << yeah << "ok");
is much more clear to me than:
LLVM_DEBUG(cout << "whatever stuff here"
<< yeah << "ok");
To be specific, excess wrapping and clutter is what I would find detrimental.
-Chris
I completely agree with this point, but then aren't you trading off one aspect of clarity for another? It is a problem with the C preprocessor that hits many projects and the equivalent to the namespace solution for macros is to add a prefix specific to the project. Ie, use LLVM_DEBUG rather than DEBUG.
The issue of clutter and excess wrapping is a secondary issue as much of the code in LLVM already is excessively wrapped and, to my eyes, borderline unreadable.
At the risk of starting a major thread that has surely been covered many times before: Is there a reason to still cling to the 80 column limit and not consider expanding it to a controversial 100 columns?
Dominic
I only have an asr-33 (http://images.google.com/images?hl=en&q=asr-33&btnG=Search+Images&gbv=2 for the culturally challenged) hooked up to my 8 core box. It features 10 CPI and 7.2 inches wide, so only 72 characters; the nice thing is that those pesky 10,000 line functions easily fit on the 1000' roll.
I completely agree with this point, but then aren't you trading off
one aspect of clarity for another? It is a problem with the C
preprocessor that hits many projects and the equivalent to the
namespace solution for macros is to add a prefix specific to the
project. Ie, use LLVM_DEBUG rather than DEBUG.
It hasn't been an issue so far.
At the risk of starting a major thread that has surely been covered
many times before: Is there a reason to still cling to the 80 column
limit and not consider expanding it to a controversial 100 columns?
This isn't open for debate and is covered in the coding standards:
http://llvm.org/docs/CodingStandards.html#scf_codewidth
-Chris
This thread suggests that it is now.