[fetter-devel] Request for comments on new interface

[Rayiner Hashem]

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

I like the idea of integrating with ASDF, except I don't have the
foggiest idea where to start extending it. I suppose that's what the
internet is for :)

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

Thoe host parameter is necessary so Verrazano knows where to find
GCC-XML, and what compiler to target.

> Does  the vzn host change the vzn support code to be embedded in the
> *library.lisp?

Changing the host causes the following changes (for C++ code):

- All function and method symbols get changed because of name-mangling.
- All class sizes and offsets change because of differing layout algorithms.
- Constants embedded in virtual dispatch functions change for the same reason.

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

I'm sure things could theoretically be parameterized, but you'd
basically just have multiple copies of the binding, one for each
compiler. It'd look like:

(cond
  ((eq compiler :vc++)
    ...cairo-library.lisp generated for vc++...)
  ((eq compiler :g++)
   ...cairo-library.lisp generated for g++...))

Pretty much the only declarations that could be hoisted outside that
cond are enumerations, #define's, and simple structures.

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

Yes, it's the issue of "from which include files are symbols to have
bindings generated". The current options I'm considering:

:strict - Only consider headers explicitly listed
:helpful - Consider headers in the same directory as ones listed

These are terrible names. I'm at a complete loss for anything both
succinct and descriptive enough, though.

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

Okay then, let's do this. I'll add the features that have been
requested (customizable naming), and clean up the naming of functions.
That should be "reasonable enough". Moreover, any interface is going
to be a thin veneer over the procedural interface, so most of the work
implementing this isn't going to be wasted (and indeed can exist in
parallel), if we make an ASDF interface.

Sincerely,
    Rayiner Hashem

>
> kt
>
>
>