[LLVMdev] Ideas for making llvm-config --cxxflags more useful

[Tom Stellard]

On Mon, Aug 03, 2015 at 10:51:15AM -0700, Chris Bieneman wrote:
> 
> > On Aug 3, 2015, at 10:30 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> > 
> >> 
> >> On Aug 3, 2015, at 10:24 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote:
> >> 
> >> Hey Tom,
> >> 
> >> I’m not a regular user of llvm-config, but this sounds completely right to me, and it would be a significant improvement over what we have now.
> >> 
> >> The only question I want to raise is, what about NDEBUG? There are headers that conditionalize on NDEBUG, which could lead to ABI incompatibility in the C++ API.
> > 
> > Is it something that can be fixed or would it be too complicated to handle? 
> 
> I think this would need a case-by-case determination that I haven’t done. There are quite a few occurrences of NDEBUG in headers:
> 

I think the issue with NDEBUG has been raised in the past, but I can't
find the email thread.  As I recall the suggestion was to replace NDEBUG
in headers with something like LLVM_NDEBUG.  I think this makes sense.
Is there any downside to making this change?

-Tom



> > grep -r NDEBUG ./include/ | wc -l
>       77
> 
> I imagine many of these aren’t actually ABI issues, but I know that ABI issues have existed in the past.
> 
> -Chris
> 
> > It would be nice in general to be able to link a “Non assert” build of Clang with an “Assert" version of  LLVM (and vice-versa). 
> > 
> > And on the original topic: +1 for Tom proposal/goal, it makes sense to me.
> > 
> > —
> > Mehdi
> > 
> > 
> > 
> >> 
> >> Thanks for doing this,
> >> -Chris
> >> 
> >>> On Jul 30, 2015, at 1:04 PM, tom at stellard.net wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> My understanding of llvm-config --cxxflags is that it is supposed to report
> >>> which flags are necessary to compile a program that will include LLVM's
> >>> headers and link against its libraries.  What it currently reports is
> >>> all of the flags which were used to compile LLVM.  This is not very useful,
> >>> because users are required in most cases to filter out flags they don't
> >>> want.
> >>> 
> >>> I would like to try to fix this so that it reports only the bare minimum
> >>> of required flags.  As an example here all the flags that it reports in
> >>> my autoconf build of llvm:
> >>> 
> >>> -I/usr/local/llvm/3.8/include
> >>> -D_DEBUG
> >>> -D_GNU_SOURCE
> >>> -D__STDC_CONSTANT_MACROS
> >>> -D__STDC_FORMAT_MACROS
> >>> -D__STDC_LIMIT_MACROS
> >>> -O3
> >>> -fomit-frame-pointer
> >>> -std=c++11
> >>> -fvisibility-inlines-hidden
> >>> -fno-exceptions
> >>> -fno-rtti
> >>> -fPIC
> >>> -ffunction-sections
> >>> -fdata-sections
> >>> -Wcast-qual
> >>> 
> >>> Of these flags the only ones that are really required are (c++ experts
> >>> please correct me if I'm wrong here):
> >>> 
> >>> -I/usr/local/llvm/3.8/include
> >>> -D__STDC_CONSTANT_MACROS
> >>> -D__STDC_FORMAT_MACROS
> >>> -D__STDC_LIMIT_MACROS
> >>> -std=c++11
> >>> 
> >>> Technically the -D__STDC* macros are only required if you include
> >>> Support/DataTypes.h, but I think that is hard to avoid.
> >>> 
> >>> As I understand, The rest of the flags are not required in 100% of the
> >>> use cases.
> >>> 
> >>> My proposal for fixing this is to remove everything but the 5 options listed
> >>> above.
> >>> 
> >>> For flags like -fno-rtti (are there others?) that are required in some cases
> >>> (I think -fno-rtti is required only if you sub-class LLVM objects), I would propose
> >>> adding a separate flag like --uses-rtti.  This would give users more fine-grained
> >>> control over which flags they use, and also would let them choose the correct
> >>> flag since, for example, -fno-rtti is not understood by MSVC.
> >>> 
> >>> How do people feel about this proposal?
> >>> 
> >>> Thanks,
> >>> Tom
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >> 
> >> 
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>