[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] Disable #error?
From:       Joe Groff <arcata () gmail ! com>
Date:       2014-01-17 16:52:36
Message-ID: CALz=kugkUuKQ_nOxrRNhChpMY4Y4huR+f4c6ue9h_rT9KZ42ZA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


I wrote a similar tool for the Clay language a while back (
https://github.com/jckarter/clay/blob/master/tools/bindgen.clay). I was
able to use Clang's source information to filter the output to only
translate definitions from headers related to the library of interest, and
it worked well in practice without any modifications to the original
headers or hacks to Clang.

-Joe


On Thu, Jan 16, 2014 at 12:25 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2014-01-16 21:08, Sean Silva wrote:
>
>  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.
>>
>
> So mean, when I process the umbrella header I would create D modules for
> the private headers included by the umbrella header?
>
> How do I know if the origin of a declaration is in a private header file
> or from a header file in a completely different library?
>
>
>  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....
>>
>
> If I managed to properly translate #include directives I should be able to
> get the same structure when translating the umbrella header. Or the user
> have to do some final tweaks manually to get the correct structure. Hmm, it
> seems very hard to, in general, do a completely automatic translation.
>
>
> --
> /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">I wrote a similar tool for the Clay language a while back (<a \
href="https://github.com/jckarter/clay/blob/master/tools/bindgen.clay">https://github.com/jckarter/clay/blob/master/tools/bindgen.clay</a>). \
I was able to use Clang&#39;s source information to filter the output to only \
translate definitions from headers related to the library of interest, and it worked \
well in practice without any modifications to the original headers or hacks to \
Clang.<div> <br></div><div>-Joe</div></div><div class="gmail_extra"><br><br><div \
class="gmail_quote">On Thu, Jan 16, 2014 at 12:25 PM, Jacob Carlborg <span \
dir="ltr">&lt;<a href="mailto:doob@me.com" target="_blank">doob@me.com</a>&gt;</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-16 21:08, Sean Silva \
wrote:<br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> I don&#39;t see the problem. Just parse the public umbrella \
header. Clang<br> keeps accurate source information and can tell you which file \
each<br> declaration is in, and can even tell you if a file is a system header or<br>
not.<br>
</blockquote>
<br></div>
So mean, when I process the umbrella header I would create D modules for the private \
headers included by the umbrella header?<br> <br>
How do I know if the origin of a declaration is in a private header file or from a \
header file in a completely different library?<div class="im"><br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Also, using the private, internal organization of the \
library&#39;s headers<br> to determine the actual user-facing module structure of the \
                D API seems<br>
*really* unwise....<br>
</blockquote>
<br></div>
If I managed to properly translate #include directives I should be able to get the \
same structure when translating the umbrella header. Or the user have to do some \
final tweaks manually to get the correct structure. Hmm, it seems very hard to, in \
general, do a completely automatic translation.<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>



_______________________________________________
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