Date: Tue, 19 Jun 2001 15:31:42 -0400 From: "Antoine Beaupre (LMC)" <Antoine.Beaupre@ericsson.ca> To: Alexander Langer <alex@big.endian.de> Cc: freebsd-libh@FreeBSD.ORG Subject: Re: Details on project status Message-ID: <3B2FA89E.4040501@lmc.ericsson.se> References: <3B265389.5030308@lmc.ericsson.se> <20010614181400.D3411@zerogravity.kawo2.rwth-aachen.d>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Langer wrote: > Thus spake Antoine Beaupre (LMC) (Antoine.Beaupre@ericsson.ca): > >>I would like to get a better description at the issues at hand though: >>- What is the problem with the make(1) build? > > Well, at the moment it's just a hack: > > - If you ran it with NO_QT for the first time, you have to "make > clean" the whole tree before actually a compile without this > options works. Same for TVision. > So if we want to build three versions of the libs later (both, > Qt only, TVision only) we need three steps. > I'd prefer the following at the moment: > - build creates a new directory as the old kernel compile did > it: compile/{text,graphics,graphics+text} maybe. > - all .o files are placed in this directories with a correct > Makefile, i.e. with the NO_* options set accordingly. > - the libs are also placed in this directory > - both, a statically linked bin/tclh and a dynamically > linked tclh are placed in this directory. > Currently, I prefer this scheme because it's easier to > develop it :-) (well, you don't have to search for the > libs in /usr/obj if you want to test stuff w/o installing them) > Later, I'd like to see libh use /usr/obj as every other part > of the system, which is the most clean solution (imho). > in /usr/obj, there will be three subdirs as well unter libh > (text, graphics, text+graphics again .-) > > Since implementing the first method for only a temporary amount of > time is useless, I prefer /usr/obj as a goal. If anyone disagrees > here, please tell me. This sounds good. > Depending on the final solution how this is implemented, I want > the NO_QT and NO_TVISION knobs be tweaks to decide if the > text,graphics,text+graphics versions are build in /usr/obj. Ok. I don't think I could help very much here. This requires massive compilations, and I don't have a really good beast for that. Unless someone would gratuously give me a box better than a pentium 166 with 32Mb of ram. :) > - the lib/tcl subdir is not good. It depends on the other libs > but won't get recompiled automatically if you changed anything > in the other directories' *.cd.cc files (actually, that are the only > files of interest for the tcl libs). Hmm... This is a dark spot for me. I know C well. I know TCL a bit. But both at the same time? Eek. :) >>- What exactly are the installation scripts supposed to be? TCL/libh >>scripts to perform standard fbsd install procedures? > > Yes. This is where it gets interesting. I haven't been able to get libh to compile yet. My workstation is also my "family machine" which gets (over) used by my roomates for evil purposes (read: msn and hotmail on windows since unix web browsers suck :). So in short, recompiling is always "interrupted" to say the least. I am in the process of finding a decent browser for unix and compiling some jabber client to make my "family" happy with FreeBSD. ;) More seriously, I took a look at the code and I like it. The idea of having the dual/independant text/graphics mode is really attractive and creating UIs seems to be pretty straightforward. As soon as I get libh examples running, I'll start to code. Unfortunatly, I'll go on vacation this week-end, so don't expect me to produce anything until next week. What's more, I work full time here, so I don't have a lot of time on my hands. >>I am interested in the freebsd install process and general configuration >>structure... > > see libh/release/scripts/ :) That's good. libh is much more advanced than I thought. >>I personnally think that the main distribution should move to a more >>package-like system where files installed would get indexed... > > I agree. <aaaaaaah....> first time I see a glitch of interest in that by *anyone*. This is good. :) >>The 250+ bin.xx files have made their time. > > Since people are still doing floppy-installs, the package-like system > still has to fit into this scheme. Oh, I totally agree with that. Even if I don't believe a single soul did a floppy install in the last year, we have to keep it as a possibility. > However, it should be no problem to split system-packages up into .xx > files and place these onto the floppies. And anyways, there's always a size limit on the media. We have to keep that in mind. >>- changing the make release process (eek!) > > eek! :-) Actually, I thought a bit more about that, and well... Doesn't the release process actually installs files in a temporary directory and then just package that? It shouldn't be too hard to hack into that... >>- me moving from -stable to -current on my workstation (eek! :) > > I have a semi-working current again since yesterday :-) I have been following the -current mailing list for a while now, and I think -current is not for me. I can't afford that on my family machine. ;) It should be possible to hack on libh on -stable anyways (?). >>Anyways, I unfortunatly don't have a lot of time on my hands, but I >>could start working on this on my spare time... > > Just let's make sure we don't duplicate work. Don't worry about that for now. :)I'm just one curious geek. I'll tell you when I'll start coding, and on what. :) > Alex A. -- Antoine Beaupré Jambala TCM team Ericsson Canada inc. mailto:antoine.beaupre@ericsson.ca 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?3B2FA89E.4040501>