[fetter-devel] Possible solution for multiple includes

[Kenny Tilton]

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