[fetter-devel] Possible solution for multiple includes

[Rayiner Hashem]

> At least this is my understanding how the C pre-compiler / compiler
> combo works. We should mimic that as close as possible to not
> introduce effects the C environment does not see and which causes
> unwanted behavior then on the VZN / Lisp side.

Yep, that's an apt description of how it works. However, Vzn doesn't
need to mimic the process, as GCC-XML fully emulates the behavior of
the C compiler.

The way Vzn works is that it translates the defbinding form into a
.cpp file which is compiled by GCC-XML. It doesn't do any of its own
header-file searching (which makes :search-mode a painfully bad name
for the pruning algorithm!), GCC-XML takes care of all that, simply
telling Vzn what definitions it found and the names of the headers in
which it found them. The result is that the XML file parsed by Vzn to
generate its IR contains only the definitions that would be seen by
the C compiler compiling the equivalent .cpp file. That means that no
matter what magic is used to distinguish between various library
versions or multi-threaded/single-threaded versions, GCC-XML has
already taken care of it by the time Vzn ever sees any definitions.
Eg: if a header file has an #ifdef PTHREADS that decides whether to
include foo.h or foo-mt.h, Vzn will only get the definitions
corresponding to the correct header.

What this proposal is about is trying to figure out how to prune the
original set of definitions to find the set to actually generate
bindings for. The pruning process cannot introduce inconsistent
definitions; it can merely preserve undesirable ones. Eg: expat.h
resides in /usr/include and includes stdlib.h. You probably don't want
declarations for stdlib.h in expat-library.lisp, but the
directory-searching proposal will cause just that to happen.
Fortunately, expat only needs three headers, so it is easy to use the
"strict" mode and specify everything explicitly. Indeed, libraries
that tend to have enough headers to make to directory-searching mode
worthwhile also tend to have their own subdirectories in /usr/include.

I hope that clarifies the issue, and that I didn't misunderstand your
point completely :)

>
> Ooookkaaayyyyy.....
>
> Great work so far! Please keep going!

Thanks a lot!

Sincerely,
    Rayiner Hashem

>
> Thanks!
>
> > Sincerely,
> >     Rayiner Hashem
> >
>
> Cheers,
>        Frank
>
> > On 10/7/05, Kenny Tilton <ktilton at nyc.rr.com> wrote:
> >
> >>
> >>
> >> Andy Cristina wrote:
> >>
> >>
> >>> On 10/7/05, Kenny Tilton <ktilton at nyc.rr.com> wrote:
> >>>
> >>>
> >>>
> >>>> I have joked before about the downside of generating bindings
> >>>> only for
> >>>> symbols mentioned in include files actually listed in a binding
> >>>> definition, as opposed to files reached via nested includes: large
> >>>> libraries customarily break their apis up into multiple
> >>>> includes, so
> >>>> these have to be listed in the binding definition to get
> >>>> bindings generated.
> >>>>
> >>>> I just ran into an egregious case of this as I look to see if
> >>>> vzn can
> >>>> handle wxWidgets:
> >>>> <many headers>
> >>>>
> >>>> <g>
> >>>>
> >>>> Well, it is not that hard to paste the same list into a binding
> >>>> defintion, but it occurred to me that there is a natural
> >>>> solution to
> >>>> this minor annoyance. What if vzn generated bindings for any
> >>>> include
> >>>> found in the same directory tree as any listed include?
> >>>>
> >>>> There is a gotcha here, perhaps. I gave up fighting VC++ at one
> >>>> point
> >>>> and just copied the headers for a package into /vc++/vc98/
> >>>> include. So
> >>>> one would now be back to pulling in every symbol ala windows.h.
> >>>> But! In
> >>>> this case, the source all includes "wx/wx....h", so I will be
> >>>> creating a
> >>>> "wx" subdirectory under the vc++ include directory, and the
> >>>> scheme I
> >>>> propose would thus work.
> >>>>
> >>>> But! number two is that maybe I gave up too fast on vc++. It
> >>>> does allow
> >>>> specification of other search paths for includes. I tried that
> >>>> without
> >>>> success on something or other, but probably that could have been
> >>>> made to
> >>>> work, and again this scheme would hold up.
> >>>>
> >>>> I have not thought this through exhaustively. Can anyone see an
> >>>> objection? Obviously the big one would be: vzn cannot see the
> >>>> paths! Can it?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> Please PLEASE make this an option in the binding if you go this
> >>> route.
> >>> Creating a binding file isn't something you do very often, and I
> >>> think spending the time to list every header you want included isn't
> >>> that high a cost. Especially if you've commited to a library that
> >>> would make you do the same thing in a C program.
> >>>
> >>>
> >> No, a C program can include "wx.h". For example, the Life demo in wx
> >> includes just wx.h and minifram.h, which latter I guess is an oddball
> >> widget that gets left out of wx.h to avoid bloat. So it turns out
> >> I am
> >> the one arguing for having vzn work the same as a C program, while
> >> forcing us to dive into wx.h, pull out its innards, and splat them
> >> all
> >> over the binding definition is the unreliable, unnatural, and more
> >> unwieldy approach.
> >>
> >> What happens when wx.h changes? With my scheme, one just
> >> regenerates the
> >> bindings. With yours, we now have to start over and re-rip out the
> >> contents of wx.h. Obviously suboptimal.
> >>
> >>
> >>>  If it is really a
> >>> problem, why not allow something like (include "wx/*.h") ?  That way
> >>> you don't do something that smells bad just to avoid typing.
> >>>
> >>>
> >> No, this is wrong. A wildcard (as you know) picks up every last
> >> thing in
> >> the directory, whether or not it gets navigated to via nested
> >> includes.
> >> So this is a "dumb" solution, in that it is not actually driven by
> >> the
> >> source which specifies exactly what to include. VZN ends up
> >> chewing on
> >> headers the C compielr would never look at. Ouch.
> >>
> >>
> >>>  Or
> >>> perhaps we can have a vzn utilities package that can make
> >>> bindings for
> >>> libraries... maybe put a fancy gui on it, point it at a
> >>> directory, and
> >>> it can give you a list control to select which headers to bind.
> >>>
> >>>
> >> But an automatic solution is possible and trivial (iff vzn can see
> >> paths), so why throw up your hands and force a totally error-prone
> >> and
> >> tedious manual selection?
> >>
> >>
> >>>  I
> >>> haven't really thought this out; I have been awake a very short time
> >>> and don't really have the ability to hold a thought for more than a
> >>> minute or so.
> >>>
> >>>
> >> Noted. :)
> >>
> >>
> >>>  But the idea of silently including things smells really
> >>> bad to me.
> >>>
> >>>
> >> "Silently"? That is exactly what every build of a C application does,
> >> and it guarantees that the right things get pulled in in the right
> >> order. You make it sound bad. What is bad is reaching into the wx
> >> internals instead of just listing the same includes a wx app would
> >> include in the .c files.
> >>
> >> kt
> >>
> >>
> >>
> >> _______________________________________________
> >> fetter-devel mailing list
> >> fetter-devel at common-lisp.net
> >> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel
> >>
> >>
> > _______________________________________________
> > fetter-devel mailing list
> > fetter-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel
> >
> >
>
>