[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] Disable #error?
From: Sean Silva <silvas () purdue ! edu>
Date: 2014-01-16 20:08:12
Message-ID: CAHnXoan-4HCr1ZCGDwr2BqogrrjV-2PBcRyF=r1-Je88YpsBig () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Jan 16, 2014 at 2:40 AM, Jacob Carlborg <doob@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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, \
Jan 16, 2014 at 2:40 AM, Jacob Carlborg <span dir="ltr"><<a \
href="mailto:doob@me.com" target="_blank">doob@me.com</a>></span> wrote:<br> \
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On 2014-01-15 22:09, Sean Silva wrote:<br> \
<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> The cleanest thing in your particular usecase is to just \
ignore that<br> header if you hit that sort of #error, since you will end up \
including<br> it through it's "proper" user-facing header when \
processing a different<br> header. Or is there some impediment to doing that?<br>
</blockquote>
<br></div>
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.</blockquote> <div><br></div><div>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.</div> \
<div><br></div><div>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....</div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div \
class="im"><br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Otherwise, it's really a discussion about "where do \
we put in a gross<br> hack to trample the source code's intent and forcibly \
ignore the check<br> and #error". That gross hack could be in clang, it could be \
done by sed,<br> it could be done in memory on the file buffers, it could be done \
by<br> detecting such errors and reparsing with -D__INCLUDED_UMBRELLA_H (or<br>
whatever the guard macro is), or any of a number of techniques. Without<br>
a really compelling use case, my gut is to not want that hack to live in<br>
clang.<br>
</blockquote>
<br></div>
Hmm, using the -D flag is a pretty good idea, as a workaround. That wouldn't \
require me to change any code.</blockquote><div><br></div><div>Glad the idea was \
useful to you.</div><div><br></div><div>-- Sean Silva</div> <div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br> <br>
-- <br>
/Jacob Carlborg<br>
<br>
______________________________<u></u>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" \
target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br> \
</div></div></blockquote></div><br></div></div>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic