[cfe-dev] Disable #error?

[Sean Silva]

On Thu, Jan 16, 2014 at 2:40 AM, Jacob Carlborg <doob at me.com> wrote:

> On 2014-01-15 22:09, Sean Silva wrote:
>
>  The cleanest thing in your particular usecase is to just ignore that
>> header if you hit that sort of #error, since you will end up including
>> it through it's "proper" user-facing header when processing a different
>> header. Or is there some impediment to doing that?
>>
>
> This doesn't really work. The problem is the tool is designed to translate
> header files one by one. The reason for that is that the C #include
> directive is so different from how modules work in D. I don't want to end
> up with one single enormous D module which contains declarations for a
> complete C library and half of the C standard library. Therefore I'm only
> translating what's actually declared in the header file being translated.


I don't see the problem. Just parse the public umbrella header. Clang keeps
accurate source information and can tell you which file each declaration is
in, and can even tell you if a file is a system header or not.

Also, using the private, internal organization of the library's headers to
determine the actual user-facing module structure of the D API seems
*really* unwise....


>
>
>  Otherwise, it's really a discussion about "where do we put in a gross
>> hack to trample the source code's intent and forcibly ignore the check
>> and #error". That gross hack could be in clang, it could be done by sed,
>> it could be done in memory on the file buffers, it could be done by
>> detecting such errors and reparsing with -D__INCLUDED_UMBRELLA_H (or
>> whatever the guard macro is), or any of a number of techniques. Without
>> a really compelling use case, my gut is to not want that hack to live in
>> clang.
>>
>
> Hmm, using the -D flag is a pretty good idea, as a workaround. That
> wouldn't require me to change any code.


Glad the idea was useful to you.

-- Sean Silva


>
>
> --
> /Jacob Carlborg
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140116/291c18a0/attachment.html>