[fetter-devel] Possible solution for multiple includes

[Rayiner Hashem]

> No, I do *not* want to have an all-in-one big file solution! I like
> VZN to generate the stdlib-library.lisp automatically because I said
> I want Freeglut and Freeglut depends on it. I thought it could work
> this way:
>
> 1. Look for dependencies in the bindings definition for the lib.
> 2. For all dependent libs generate the xxx-library.lisp file. Place
> them in a repository directory.
> 3. Generate ASDF code that insures dependencies are met and code is
> loaded when needed.
>
> This way, if I once have generated a stdlib-library.lisp file and I
> work on another project that also needs that lib, it is already there.

Yes, that would also work. Actually, Vzn has no way of knowing what
constitutes a library, so you'd have to replace "lib" with "header
file" in your algorithm, but the result would be the same. The
question is whether the benefits are worth the tradeoff, the tradeoff
being increased implementation complexity as well as tying users to
ASDF.

> Well, partly because I have still not understood how VZN can find all
> dependent bindings and only those that are needed by the one lib I
> want to use. I still have that lib in my head that relies on 100
> other libs where one particular type definition is specified in the
> 100th include file on the 20th include level.

Vzn's pruning pass makes sure that if the binding requires a
definition from a header file that will not be included (as a whole)
in the generated output, that at least the parts of the header that
are required to make the binding work are still generated. Ie: if you
want code generated for foo.h, and foo.h uses a typedef that is in
bar.h (where bar.h is the aforementioned 100th include file, and is
*not* going have bindings generated for it), then Vzn will still
output that typedef from bar.h, even though bar.h will not be output
as a whole into the binding.

Code-wise, Vzn basically uses a tracing algorithm. It starts by taking
the original set (the "everything" that the C compiler would see), and
marking all definitions as "not reachable". It then goes through all
the header files that the user wants bindings for (eg: gl.h,
freeglut.h), and adds their definitions to a root set. It then
recursively marks everything reachable from the root set. Finally, it
prunes all definitions that weren't marked reachable. This does result
in some duplicated definitions in library files (eg: most Windows
libraries will define DWORD or something from the windows headers),
but they are all in seperate packages, so the symbols don't conflict.

Sincerely,
    Rayiner Hashem

>
> 73 (Ham radio code for: "best wishes and regards")
>
>     Frank
>
>
> _______________________________________________
> fetter-devel mailing list
> fetter-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/fetter-devel
>
>
>
>