[openbeos-build-team] Re: Goals for the new build system
- From: "David Reid" <dreid@xxxxxxxxxxxx>
- To: <openbeos-build-team@xxxxxxxxxxxxx>
- Date: Thu, 4 Jul 2002 19:44:46 +0100
Ryan,
Maybe it wa a bit harsh, but then suggesting we rewrite the entire build
system is pretty dramatic!
Basically I'm very concerned that the amount of work that Ingo and I put
into getting the kernel working as it does now will be repeated if we try to
reinvent the wheel. I'm also quite amazed that what we ended up with is
flexible and works! I'm not talking about the entire build system, just the
"strange" and "bizarre" bits we had to write (the config rule for the kernel
springs to mind). These seem to be regarded as obscene hacks, and I suppose
from a purist standpoint they could be seen as such, but the fact is they do
something that for 2 days looked impossible! They also do it without
involving a lot of extra files and some of the other ideas we came up.
There are a lot of things that I don't like about the build system. I'm more
than willing to work with you to improve it, but you haven't asked me about
any of this stuff! If you had questions why didn't you ask? The libc/m thing
is a good example. It's actually pretty damn straightforward, but the size
of the file and all those "almost but not quite identical" lines have a way
of discouraging browsing, but it's all logical and ordered - if it wasn't we
wouldn't be building :) Phrases such as "I guess not closely enough to
understand the convoluted things it is doing...which tends to prove my
point" could have been avoided by a few simple questions. I do generally try
to help?!
I'm not fighting you, just trying to be realistic. I still remember that 10
days of my life (and if my life hadn't gone south in even bigger ways since
then I would probably still be having nightmares about it :( ) where I felt
like the gladiator in the lions pit trying to get Jam to do what should have
been simple (to my mind) builds. Now I suppose I have to say that my area of
concern is very much the kernel and that has more issues about building than
most other parts of obos.
Realistically, Jam has issues that make it less than perfect for complex
builds. Make has issues that make it awkward for simple builds. Ant has
issues as it's written in Java! So, which do we choose? None are perfect and
there is no "one size fits all" for this problem - but please, please,
please don't try to be gung ho and diminish the effort than both Ingo and I
expended trying to fix the kernel build with such sweeping phrases as "just
a few days of trial and error hacking".
I can still remember one night on IRC while Ingo and I tried to fix the
final part of the puzzle your arrival in the channel and your subsequent
acting like our problem wasn't an issue - despite not really comprehending
the complexity at that point. From the perspective of "the people in the
trench's" this wasn't a good attitude and did smart a little. Since then the
build team has been created and you've been made the leader of that team.
This is a good idea (but then I would say that as I was the one who
suggested it!!) but there hasn't been much progress thus far. The whoole
issue of the CVS reorganisation seems to have the opposite effect to that
intended, namely it has stifled development.
I'm afraid your email just touched a nerve as I saw another round of
throwing out what works in search of a "purer" solution that isn't needed
and perhaps I did take it a little personally.
As for people contributing, I note that since we've been building on Linux
we've gained a number of people working and contributing on the kernel and
our "press" has gotten a lot better.
david
----- Original Message -----
From: "Ryan Leavengood" <leavengood@xxxxxxxxxxxx>
To: <openbeos-build-team@xxxxxxxxxxxxx>
Sent: Thursday, July 04, 2002 7:06 PM
Subject: [openbeos-build-team] Re: Goals for the new build system
>
> >Points...
> >
> >1) what we have now actually works very well and has proven to be
> robust to
> >lots of experimentation so I don't really think some of your points
> are very
> >valid
>
> OK, then why the hell do we have a "build team"? Seriously, if I can't
> try to improve the build system we have, I will quite quickly resign
> from this position. I don't want to sounds like a primadonna, but this
> is not a paying job, and if I want people dictating some shitty build
> system to me, all I have to do is go back to work. Especially if I
> have to maintain said build system. I just want to improve things and
> I feel like I'm constantly battling against you David, which gets
> incredibly frustrating. And you guys wonder why no one contributes to
> this project?
>
> David: I know you put a lot of work into creating what we have now, and
> maybe my critiquing of it comes off to you as a personal attack, but it
> is not. Maybe I don't yet understand "the big picture", but either way
> I'll try my suggestions and see what happens. Maybe you will be right
> and what we have now is the best way to do it. But I'm not resigned to
> just accept that as fact.
>
> >2) libc/libm will be moved out of the kernel directory and the actual
> usage
> >of them is to simply include libc/libm - which is exactly what you
> want. I
> >wonder how closely you've looked at the Jamfile in kernel?
>
> I guess not closely enough to understand the convoluted things it is
> doing...which tends to prove my point.
>
> >3) the reason that libc/m is built in kernel is that's the directory
> where
> >it needs to be built - nothing more
>
> If you say so.
>
> >4) there is as little hard coding as I could get away with. the glob
> rule
> >won't work as there are files in directories we build for some thing
> but not
> >others and some we don't even build at all at the moment. What we need
> is to
> >have a single place where we define the files that currently make up a
> >"section" and then simply include the "section" when we build. this
> gives us
> >the best of both worlds and doesn't remove any of our flexability.
>
> Sounds interesting.
>
> >5) the objects directory is a pain but one I've grown used to and now
> quite
> >like. Searching for references in the directories becomes much easier
> when
> >you don't have object files and keeping cvs up to date is easier and
> cleaner
> >as well. why change it to make life harder???
>
> I don't believe getting rid of the objects directory makes life harder,
> but I agree with your points regarding searching through the source and
> CVS usage. Therefore I will keep this if I do any build system
> changes.
>
> >I actually think that trying to have a major overhaul now would be a
> >disaster! What's needed isn't an overhaul of the build system but
> rather an
> >overhaul of the directory tree - and that is in the works.
>
> OK. Then again I fail to see the point of this whole "build team"
> which I can remember everyone lamenting about before.
>
> >Given all of your talking "up" of Jam I was suprised to read some of
> this -
> >isn't it the all powerful and overwhelming tool you would lead me to
> >believe??? :)
>
> I don't see how any of my points had anything to do with Jam being a
> bad tool. I just feel the current use of it is bad. I suppose no one
> has ever written bad Makefiles? I know the answer to that, so by your
> logic make is also a bad tool.
>
> I also never said that Jam was the savior of build tools, just that I
> feel it is better than make. I mean *someone* needs to respond to
> emails with subjects like "I HATE JAM!", which was mostly the result of
> lacking knowledge of said tool.
>
> Ryan Leavengood
> OpenBeOS Build Team Lead
>
>
Other related posts: