[fetter-devel] Possible solution for multiple includes

[Frank Goenninger - PRION Consulting]

Am 08.10.2005 um 23:43 schrieb 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 :)

Seems as if I misunderstood a couple of things. Thanks for  
clarification!
I will have to look into GCC-XML further, but I still don't see why  
you don't do what C does:

All the includes are included. That, for me, means: Everything in  
every included include-file has to be declared/defined: functions,  
data types, constants, ...

As for handling the declarations of stdlib.h in expat-library.lisp:

Why not generating stdlib.lisp in a well-defined place (= repository)  
and then use ASDF to load the dependent file stdlib.lisp when loading  
expat-library.lisp.
Each time a binding wants to use stdlib.h it checks (via time stamp)  
if the generated stdlib.lisp is still valid (= younger than the  
source file stdlib.h). If not, the stdlib.lisp file has to be  
regenerated, of course...

Wrong path of thinking, this? Why?

Thanks for commenting.

Cheers
    Frank


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: Signierter Teil der Nachricht
URL: <https://mailman.common-lisp.net/pipermail/fetter-devel/attachments/20051009/fdf20dba/attachment.sig>