[fetter-devel] Possible solution for multiple includes

Sun Oct 9 19:48:51 UTC 2005

Am 09.10.2005 um 20:36 schrieb Kenny Tilton:

>
>
>>>
>>> The problem is on win32, where something like FreeGlut.h (IIRC)  
>>> may  include a little thing called "windows.h".
>>>
>>> Want to guess how big was the resulting freeglut-library.lisp? :)
>>>
>>
>>
>> A recall you said something about 700k ... Or even more ...
>>
>>
>>>
>>> Now leave aside that problem (windows.h including everything  
>>> under  the sun whether freeglut needs it or not). How about  
>>> stdlib.h,  which Freeglut likely does need. Do we want bindings  
>>> for that?  Absolutely not if we are just trying to get to  
>>> Freeglut. Freeglut  has an API, and that is all we want.
>>>
>>
>>
>> I fully agree. This makes the "include challenge" some degrees  
>> more  complex: Find out what Freeglut needs - recursively, because  
>> there  might be a #define HAHA  HEHE in file "a.h" and the #define  
>> HEHE HIHI  in file "b.h" and then the #define HIHI 1 in file  
>> "c.h", each having  more than just this #define in it and there  
>> bringing along more stuff  and bindings. So, we need to cut away  
>> all the things that are "not  requested" by Freeglut ... Doable, I  
>> think. But why? Speed? Size?  Well, yes, of course. But a couple  
>> of more GB of main memory and  we're done ;-)
>>
>
> Because it is doable. And ACL takes 4-5 minutes to compile a 700k  
> Lisp file. And I would like to open the thing and look at the API.  
> It is bad enough that internals of Freeglut will end up in the  
> binding file, but the entire Windows operating system? I /did/ open  
> the 700k thing, and it was just hilarious to see what was in there  
> (and impossible to see Freeglut).
>
> To be honest, I am not sure why I have to justify why it is bad to  
> use a 700k Lisp file just to get to a terribly small API like  
> Freeglut.

You don't have to justify it, of course! Being serious now: I am  
completely agreeing that a generated file has to be as lean as  
possible. I once had to debug machine generated code and it was a  
nightmare. And I am a fan of the KISS principle.

> What happened to the fine German tradition of precision  
> engineering? <g>

Still trying to get my head away from the C scheme of thinking here.  
I am still so used to the fact that the CPP output (if you look at  
this directly, which you normally wouldn't do) is some Megabytes of C  
code in some of my projects.
>>>
>>> True, some C junkie might get off on having stdlib at their   
>>> disposal from Lisp, but that is completely unrelated to getting   
>>> bindings to Freeglut, and they should be getting those bindings  
>>> by  making stdlib-binding.lisp and using VZN on that.
>>
>> Right. And VZN and ASDF may work together to do this. If VZN  
>> creates  bindings for every single .h file / lib it finds and puts  
>> everything  in a well-known place (a repository) then we're done.  
>> (see my other  post on this). No? I wonder if I am still on the  
>> wrong thinking  track ...
>>
>
> Yes, I think you are not thinking "API". The "I" stands for  
> interface. <g> Ideally, vzn would have access to something like  
> the .DEF files which tells VC++ which functions go in the DLL --  
> well, maybe not. I like that vzn will get me into functions the  
> author did not think to export, because I ran into that with FTGL.
>
> Anyway, what track are you on that tells you a Lisp binding to  
> Freeglut should include strcat, even if it is neatly packaged in  
> stdlib-library.lisp?

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.

>
> Meanwhile, we already have a nice, easy solution to the 700k  
> thing.... what problem are you trying to solve by arguing for a  
> gross abuse of machine resources and binding readility?

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. Reading VZN's code in  
detail certainly would help here but I have to admit I haven't done  
this yet. So, I beg pardon for being so stubborn or ignorant here.

73 (Ham radio code for: "best wishes and regards")

    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/5284d960/attachment.sig>