Date: 11 Aug 2002 06:01:51 -0700 From: Max Okumoto <okumoto@ucsd.edu> To: The Anarcat <anarcat@anarcat.ath.cx> Cc: freebsd-libh@FreeBSD.ORG Subject: Re: libh changes that I would like to get comments on. Message-ID: <hfy9bdczwg.fsf@multivac.sdsc.edu> In-Reply-To: The Anarcat's message of "Sat, 10 Aug 2002 12:54:56 -0400" References: <hfznwtquws.fsf@multivac.sdsc.edu> <20020810165454.GA34549@lenny.anarcat.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
The Anarcat <anarcat@anarcat.ath.cx> 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. > 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. 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. 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. > 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. > > 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 > > 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. > 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. > > > I am still using 4.5-RELEASE as my devel enviorment, but I am using > > swig 1.3.13 from /usr/ports/devel/SWIG-devel. (Note: I modifed the > > Makefile to only build tcl SWIG_LANGUAGES=3Dtcl) > >=20 > > Max Okumoto > >=20 > > % gzcat libh.tar.gz | tar -xf - > [...] > > Whoohoo! This fixes the tvision bug #5!! (see the BUGS file). Oh yea, that didn't work because the refcounting stuff from the old system. the TVision application object needs to be destroied for the cleanup routines to be invoked. > > 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. I just wrote a script to tar up the stuff I wanted people to look at. > > I totally agree to integrate this into the main branch. I think we'll > have to be really careful though, merging not all at once, but slowly, > incrementally. > > I was thinking of releasing 0.2.3, but I think we'll jump straight to > 0.3, this is just too much. :) > > Yay again! > > A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hfy9bdczwg.fsf>