Date: Mon, 12 Aug 2002 11:01:15 -0400 From: Antoine Beaupre <anarcat@anarcat.ath.cx> To: Max Okumoto <okumoto@ucsd.edu> Cc: freebsd-libh@FreeBSD.ORG Subject: Re: libh changes that I would like to get comments on. Message-ID: <5988A99A-AE04-11D6-BD85-0050E4A0BB3F@anarcat.ath.cx> In-Reply-To: <hfy9bdczwg.fsf@multivac.sdsc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, August 11, 2002, at 09:01 AM, Max Okumoto wrote: > 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. 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 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?5988A99A-AE04-11D6-BD85-0050E4A0BB3F>