[fetter-devel] Possible solution for multiple includes

Sat Oct 8 09:26:47 UTC 2005

Am 08.10.2005 um 04:34 schrieb 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.
>

This last statement is (or should be) true only for system libs or  
close-to-system libs. One of the big advantages of the Unixes on this  
planet is that you are not forced to put all the libs under a pre- 
defined directory. For all my own software I have opted to install  
these under "/opt". So, my software package "tuba"   creates/has  
directories like:

/opt/tuba
/opt/tuba/bin
/opt/tuba/include
/opt/tuba/lib
/opt/tuba/man
/opt/tuba/etc

And yes, your are guessing correctly that all the include files are  
put under /opt/tuba/include -  there are sub-dirs in there, too. I  
have a subcomponent CORE that has its own include files: "core/ 
core.h". Then the whole path is of course: "/opt/tuba/include/core/ 
core.h".

Now, I would want to do something like

(verrazano:defbinding
    (:name "tuba-library")
    (:nicknames "tuba")
    (:include-path "/opt/tuba/include")
    (:include "tuba.h"))

In file tuba.h, there is the #include directive for core/core.h.

Then, there is IMO no need to do a full directory search and go  
through each file in a directory. This is not what the C compilers  
(or the precompilers) do and might actually introduce inconsistencies.

A real example for this:

I have a lib (not my own, a commercial software product) that  
provides several alternatives for a lib with a corresponding include  
file for each lib all in the same include directory.

The libs represent different threading support (one without multi- 
threading support and the other one with it) and they actually differ  
in the API:

(void) getContextID (Context *context, Thread *thread);

and

(void) getContextID (Context *context);

... Same name, different parameters -  and it's plain C. How to  
decide which is the correct one? The files are named differently so  
if you explicitely say "include this file but not the other" then you  
are save.

I'd really be careful also with different versions of an include  
file / a lib. The same problem applies there, too.

The only solution for me is to traverse all include files for further  
includes in them and pull in the definitions while watching out for  
already included definitions. This should happen automagically with  
just providing the top include (see my tuba example above) and all  
definitions are seen then.

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.

Ooookkaaayyyyy.....

Great work so far! Please keep going!

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
>
>