Re: Replacement for DLLCC front-end...

Thanks Antony, this is fantastic and exactly what I suggested we could
do - it's good to see it turn in to a reality. The best thing is, it's
better than SWIG and Boost in that you don't have to recompile the
libraries -at all-.

I'll have to find some time to look further in to this and play with it.

Cheers,
Michael

Antony Blakey wrote:

>
> Hi,
>
> I've built a replacement for the DLLCC front-end using GCCXML, and
> built a simple mechanism for dealing with library differences between
> platforms. I've got one hurdle before it's done (well, releasable),
> and that's bitfield handling. It really needs to be handled in the
> DLLCC machinery i.e. alignment/access, but it seems not to be, at
> least upon my inspection of the code. I'll describe what I've built,
> and what I'm hoping is that someone with expertise in DLLCC internals
> will see enough benefit to do the DLLCC bitfield stuff.
>
> What I've built uses ExternalProcessStreams to execute gccxml (twice)
> to pick up #defines and the parsed infoset of C/C++ headers. So gccxml
> needs to be installed, and I've not done windows, although apparently
> gccxml works there as well (maybe gccxml could be a library - I don't
> know). The resulting #defines/infoset is reified in a typed tree
> structure in VW. You can then manipulate the tree fairly trivially to
> do a number of things such as:
>
>  - Replace pointer-to-functions with typedefs for use in CCallback
> casting.

>  - Build wrapper classes for structs as I've seen in CairoGraphics

>  - Add _threaded to some functions
>  - Convert #defines to/from enums
>  - Resolve system-specific (or all) typedefs so you don't see stuff
> like __darwin_fsfilcnt_t
>
>  ... and basically anything else you can imagine.
>
> Then you can generate the methods into a platform specific
> ExternalInterface sub(sub*)class, but you only need to do it for a
> specified set of function/structs etc and it will compute the
> transitive closure from the roots and only generate what you need.
>
> All of this is programatic and requires no stuffing around with C
> files or hand-editing i.e. you're in VW the entire time. It's a proper
> parser, and handles C++, including giving the mangled names using a
> variety of platform/compiler strategies, so you can link to C++
> (although I haven't reified the *entire* infoset as typed classes
> yet). It's repeatable, and can be simple re-executed on different
> platforms to build platform-specific library wrappers. A simple
> mechanism based on External-Interface-Pragmas makes
> platform-distinctions both at generation time and load time automatic
> and trivial, whilst still allowing custom code both at a library and
> per-platform level, without losing code when regenerating (it will
> delete stuff it knows it generated when regenerating).
>
> Why don't I just drop it in Store and let the market decide? Because
> I'm hoping to motive the bitfield stuff. I've got a hack but it's
> based on pre-computing all the alignment details for a given platform
> and transforming the field and replacing bitfield members with a
> padder of the appropriate size i.e. losing their declaration in the
> struct. I could automatically generate getter/setter methods for
> bitfields, but that smells bad to me and in the case of FUSE, the
> three bitfields aren't of that much interest to me. Furthermore, it
> means the library client has to know which fields are bitfields.
>
> I'm using this to generate an interface to the FUSE library which
> allows me to write user space filesystem handlers in VW (FUSE is
> OSX/Linux only). It worked fine on OSX but when I went to deploy on
> Linux the work of generating the library class and hand-editing
> preprocessed header file output again was just too much bullshit, so I
> wrote this instead.
>
> [ BTW: This is the second time I've sent this because it's not showing
> up in the lists ]
>
> Antony Blakey
> --------------------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> It is as useless to argue with those who have renounced the use of
> reason as to administer medication to the dead.
>   -- Thomas Jefferson
>
>
>