[fetter-devel] Possible solution for multiple includes

[Rayiner Hashem]

First, a technical point: yes, VZN can see the full path of each header.
Second, the solution is probably fine on Windows, where each library
typically has its include files installed to a seperate directory, but
is possibly suboptimal on *NIX, where everything is in /usr/include.
So for cases like zlib, or libelf (just to name things that I can see
in my /usr/include), there does need to be some sort of option to use
the strict semantics. However, I don't have a problem making the
directory-searching behavior the default. Even on UNIX, most libraries
are well-behaved enough to create a subdirectory under /usr/include.

Sincerely,
    Rayiner Hashem

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
>