[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.
>>    
>>
>
>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 :)
>
Funny you should mention that. I believe ASDF works the way you propose 
allowing user specification of an alternate naming scheme: one provides 
methods for this or that GF. That seems weird and user-hostile to me. if 
I see a parameter such as :lisp-name factory, I think "Bingo! What are 
the options?" ie, I know exactly where to look, even if it has been nine 
months since I generated bindings. Then I see that :lisp-naming-factory 
can be a function (as the name suggests) or one or two keywords 
specifying popular translation schemes (or nil for no translation). With 
ASDF I have to dive into the source, figure out how ASDF works, find the 
right GF, pray that i can safely override it, and put a defmethod in 
each ASD definition file (.asd) I want to get this special behavior. Ick.

>
>  
>
>>>(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.
>
Oh. Never mind. :)

>
>  
>
>>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++...))
>
OK. Well, I think this can be handled easily enough as a vzn user. There 
is enough flexibility in there.

>
>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.
>
Howseabout making it include specific?

    (defbinding....
          (include "just-me.h" ("my-tree.h" :process-nested t))

...or just:

    (defbinding....
          (include "just-me.h" ("my-tree.h" t))

with process-nested then being like an optional parameter? We might need 
file-specific control someday, and it saves making a new parameter. If 
"process-nested" sounds vague, call it "bind-nested". But making 
bindings /is/ what vzn does, so "process" works for me.


kt