[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers

Alp Toker alp at nuanti.com
Mon Nov 11 12:09:27 PST 2013


On 11/11/2013 19:16, Alp Toker wrote:
> On 11/11/2013 19:08, Chris Lattner wrote:
>> On Nov 11, 2013, at 9:56 AM, Alp Toker <alp at nuanti.com
>> <mailto:alp at nuanti.com>> wrote:
>>> Done :-)
>>>
>>> The patchset is 532K so I've put it online:
>>>
>>>   http://www.nuanti.com/tmp/llvm-api-stability/
>>>
>>> The bulk edits are split out and noted. They were refactored with an
>>> internal tool, so it's not a big hassle to keep this up to date until
>>> 3.4 is out the door.
>>>
>>> A handful of fixes were needed to add support for Release+Assert
>>> builds and these are also separate commits.
>> Whoa whoa whoa.  Why are you introducing an llvm_assert() macro?  The
>> use of assert in header files is not a problem for "libraries", it is
>> things like:
>>
>> #ifndef NDEBUG
>>   int SomeNewVariable;
>> #endif
> They're both are a problem. assert() is defined deep down in the C
> library headers and is conditional on !NDEBUG. It's not practical to
> override the preprocessor define, at least with the MSVC and OS X
> headers. (It _might_ be possible to hack around with glibc headers but
> I'm not certain.)
>
> That means that, as long as there are assert() uses in the headers and
> you want to have a standard definition usable from a non-debug build,
> you need a custom assert() macro.
>
> Even when you have a !NDEBUG build, the platform assert() is pretty
> crummy on Windows and generates, at best a UTF-16 dump, or sometimes
> just pops up a dialog. WebKit and other projects take the same approach
> and define their own assertion macros to deal with this portably.
>
> So as far as I can tell, as long as the headers use assert(), they need
> to use our own version in order for the definition to match.

Chris,

Having said that, I agree it's worth trying without llvm_assert() to see
how far it gets.

I'll pull together a rework of this patchset with just the build system
and structure changes alone to see how far it gets.

The key thing then is to make sure that it's safe to enable the
assertions in the headers if an application is built with !NDEBUG and
linked against an NDEBUG version of LLVM.

Alp.


-- 
http://www.nuanti.com
the browser experts




More information about the llvm-dev mailing list