<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>