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>