Re: libh changes that I would like to get comments on.

On Sunday, August 11, 2002, at 09:01 AM, Max Okumoto wrote:

> The Anarcat <[email protected]> writes:
>> On Mon Jul 15, 2002 at 01:04:19AM -0700, Max Okumoto wrote:
>>>
>>> Hi guys,
>>> 	I would like your opinions on some changes that I
>>> would like to make to libh.  I have built a small framework
>>> with just the UI section which is contained in the appended
>>> tar file.  But, before I spend any more time in this I=20
>>> would like people to look over the changes that I am purposing.
>>>
>>> o Makefile dependency generator
>>> 	I would like to start using 'bm' (build makefile) program
>>> 	that I put into the tools directory.  This program generates
>>> 	a Makefile with all the dependencies.
>>>
>>> 	Note: The generated Makefile is modeled after Peter Miller's paper.
>>> 	http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm-
>>> old.html
>>
>> I'd be very careful with this. I haven't looked at the bm program, so
>> I don't know if it really works.
>>
>> libh Makefile system is really obscure and fragile.
>
> Yup, I kept running into problems with the Makefiles.  While
> debuging the UI code, I usually had to delete all the object
> files, since very few of the dependancies where in the Makefile.
>
> This is why I put in the bm (BuildMakefile) program. It creates
> part of the Makefile and builds the dependancies.  The result
> would replace most of the complex stuff that already exists.

I'm getting used to bm now. It looks ok.

>> But, as always, if it works, you can go ahead. ;)
>>
>> One quick note: the new system doesn't seem to build multiple back
>> ends as the old one did (none, text, graphics, text+graphics). This is
>> mandatory. We need a text-only backend for the floppies.
>
> I will look into static linking.  With swig it shouldn't
> be that hard.   I had assumed that if we used dynamic
> linking the over all system would be smaller.

Yes. But you need to link with pretty big libraries. libc is the first 
that comes to mind:

-r--r--r--  1 root  wheel  579412 Jun 11 00:18 /usr/lib/libc.so.4

That's just too much for a floppy, especially when there's a lot of code 
in there that is simply not used.

> From my understanding we only need one static binary, and that would
> be the 'text only' version.  (Unless you are building tcl without
> dynamic loading built in.)  If the system running libh has graphic
> the Qt module can be loaded in dynamically.

Well, I see it a little differently. I think we should be able to link 
anything we want statically, simply by setting NOSHARED=yes somewhere.

It's a different issue than with *what* (qt, tvision, nothing) to link, 
IMHO. I really like the idea of choosing what gets compiled in and what 
doesn't, and the new build system shouldn't loose that.

> I think after I finish up with the UI code it really would make sense
> to move the rest of the modules in libh/lib/* over to swig.

Of course.

>> BTW, it would be nice if you could share with us how the heck this bm
>> thing works. :) I'm quite impressed at the compile time of the demo
>> you attached to this mail. Of course there's the whole TCL thing
>> that's skipped and taken care of by SWIG, but still, it's a great
>> improvement.
>
> I really need to write a man page for it :-)   If you have a chance
> please read Peter Miller's paper,  it's the basis of my program.
> I will send a description to the list in a seperate email.

I think I read that paper. I do agree that recursive make is evil. :)

>>> o Restructure the Hui subsystem into three seperate libraries.
>>> 	lib/Hui would be a virtual base hierarchy.
>>> 	lib/HuiTv would be the TVision implimentation of Hui
>>> 	lib/HuiQt would be the Qt implimentation of Hui
>>
>> That looks ok. It is indeed very nice, and the whole thing looks much
>> more isolated than before. Good work!
>>
>>> o Use swig 1.3.13 to build tcl <--> C++ glue code instead of what
>>>   we currently have.
>>> 	This supports dyanmic loading of the Hui code.  My test
>>> 	tcl script uses a vanilla tclsh binary.  It first checks
>>> 	if the shared lib exists and then loads the code.
>>
>> This is very nice. It is an additional dependency, but we didn't need
>> to re-invent the wheel and it's causing us problems.
>>
>> There is however, some problems in that area: I don't know exactly how
>> the old system worked. The whole principle of getting TCL into libh
>> was to control the execution of scripts using the safe
>> interpreters. How will this fit in the new scheme? What exactly is
>> swig replacing and how?
>
> The old system (hsystem) and Swig are equivalent.  They both take
> in a description of the C++ interfaces and create wrappers functions
> that can be called from the tcl interpreters.
>
> 	libh/bin/HuiTv_shared/HuiTv.ii vs *.cd.cc
>
> The swig input file look very similar to a standard C++ header file,
> in fact it can be but it is usually better to only put in member
> functions that you really want to export to tcl.  (Note: if you have
> worked with rpcgen it is pretty much the same thing)
>
> With the old system, the main function created the interpreter,
> registered the wrapper functions, and then entered the tcl main
> loop.  The generation of the wrapper functions is the most complex
> part of the old system.
>
> *.cd.cc -> build_systems_*.cc -> tcl_interface_gen_* -> 
> LibTclInterface_*.cc
>
> With swig the interface description is converted to wrapper functions.
> These functions follow the tcl conventions for dynamicly loadable
> modules, so its easy to load them in.
>
> *.ii -> *_warp.o
>
> Basicly swig replaces.
> 	libh/lib/tcl/*
> 	libh/include/tcl/*
> 	libh/lib/*/*.cd.cc
> 	libh/include/HSystem.*
> 	some stuff in libh/lib/common
> 	some stuff in libh/include/common

This is really nice. And I guess it means that libh won't have to be 
linked with SWIG itself. SWIG is just used in the build, right?

>> As long as these questions aren't answered, I won't be comfortable
>> with SWIG in libh.
>>
>> Oh, and a last note.. I think tclh is still needed, even if we can
>> now load libh modules through tclsh. The problem is that dynamic
>> linking (ld.elf.so) simply *won't* be available on the floppies,
>> because of the space restriction. Everything will have to be
>> statically linked, I think, to obtain optimal space tradeoff.
>
> Unless you are building a new libc, tcl uses the dlopen(), so
> that won't be an issue.  You do need a staticly linked tclsh8.3
> binary.

Fine.

>> I might be wrong here though. :)
>>
>> We'll need to run throughout space comparaison between both.
>>
>> Oh, and this also means that SWIG will be statically linked into libh
>> too? This might take up too much space too. We really have to examine
>> these issues.
>
> Only the warppers go into libraries.  Nothing else is required.

This is really marvelous.

>> Wow max, this is really great. Dynamic loading and all, you've done a
>> great job.
>>
>> Now I feel very sorry I didn't check on this earlier.
>>
>> Where is that tarball from? Is that particular code from the branch?
>> How did you generate it?
>
> Its in my checked out copy of libh.  I just haven't checked in the files
> since there needs to be alot of repo copies.  And I wasn't sure how many
> files were going to be moved/renamed.

Okay. Please provide a roadmap of how this change will have to go, which 
files will have to be merge/removed, from which branch, and which 
repo-copies will have to be done, I'll try to tackle this ASAP.

> I just wrote a script to tar up the stuff I wanted people to look at.

It would be nice to see it. ;)

A.


To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-libh" in the body of the message