[fetter-devel] Request for comments on new interface

[Kenny Tilton]

Rayiner Hashem wrote:

>The user interface for Verrazano is a bit of a kludge at the moment,
>and I've been working recently on refactoring the code to both enable
>a more sensical and straightforward UI, and also to refactor the
>internals to allow better user control in certain places. This work is
>a prerequisite for things like Visual C++ support and multiple backend
>support. Moreover, I consder a rework of the UI to be a prerequisite
>for a 1.0 release.
>
>Right now, what I have is a procedural interface to the generator's
>internals. What I need is a good way of allowing the user to specify a
>configuration. The idea is to dump the special .binding file, as Kenny
>suggested, and go with a set of macros. My first thoughts are to make
>generate.lisp look like this:
>
General observation: we should think ahead to using ASDF or mk:defystem.
This may already be doable, i have not stared at it nor am I a whiz on
either system builder. But I should be able to put the create-binding
invocation in, say, and ASDF definition, list "cairo.h" etc as
dependencies/components/modules/whatever and just use ASDF (while
maintaining not cl-cairo/generate.lisp but merely
cl-cairo/defbinding.lisp which would have everything below except the
create-binding call). Note that this sounds like but is not the same as
having a cairo.binding file parsed by create-binding.

>
>(verrazano:defbinding cairo
>  (:name "cairo-library")
>  (:nicknames "cairo")
>  (:include "cairo/cairo.h"
>            "cairo/cairo-pdf.h"))
>
>(verrazano:defhost winvc++
>  (:compiler :vc++)     ; or :g++
>  (:gccxml-path "")
>  (:gccxml-command "gccxml")
>  (:temp-directory "/tmp"))
>
As usual, I have not thought this thru, but why do we need this host
parameter? It seems to me that it would be nice to end up with a
*-library.lisp that could be used unchanged when I build on Win32 or
*nix, or (on Win32) when I toss a VC++-built library and decide to use a
G++-built library.

Does  the vzn host change the vzn support code to be embedded in the
*library.lisp? If so, is there some way that one universal albeit
host-parameterized vzn support code can be embedded, and the load
library call take a host parameter? I do not know how that could be used
to select the right vzn support library by library (on win32, i can
imagine DLLs from both g++ and vc++ being used by one application), but
if we can see the diff vzn support code (if my guess is right) I might
have some ideas.

Achieving this eliminates a parameter and makes a single source file
universal, and lets me change from VC++ to G++ for a particular library
without regenerating bindings. The latter would not happen often, but
the fact that, should it happen, I would have to regenerate the bindings
suggests to me that we are building in needless inflexibility.

>
>(verrazano:deftarget cffi-lispy
>  (:backend :cffi)
>  (:name-style :lisp-style)   ; or :c-style
>
With another recent poster, I would like to see /in addition/ the option
of supplying here a user function.

>  (:search-mode :strict))    ; or :helpful (better name???)
>
Better name for what? :) I mean, what is "search-mode"? Is this the
issue of "from which include files are symbols to have bindings
generated?". What are the options you are now considering (and their
semantics)?

>
>(verrazano:create-binding
>  :binding cairo
>  :host winvc++
>  :target cffi-lispy
>  "testsuite/cairo/cairo-library.lisp")
>
>Basically, the specification of the configuration is split up into a
>binding describing the header files to incorporate, a host describing
>the host platform, and a target describing what backend to use and
>what code generation options to enable. Common hosts like "winvc++" or
>"lingcc" would be built into Verrazano, so you could pass something
>like "verrazano:winvc++" to CREATE-BINDING, without having to redefine
>it each time.
>
>I'd love to recieve any comments that would help me make this
>interface better (or suggest to me to scrap it entirely and do
>something else :)
>
Aside from my above comments, I think this is close enough that you can
just go with it. I am guessing we are at such a high level here that
revision/refinement in the light of experience will be easy, and the
best ideas will come from trying to live with the scheme, so it is
better to push something reasonable out the door and see how it does in
the wild than to get bogged down in a debate where people are really
only guessing at what the ideal UI would be.

kt