[openbeos-build-team] Re: Goals for the new build system

  • From: "Ryan Leavengood" <leavengood@xxxxxxxxxxxx>
  • To: openbeos-build-team@xxxxxxxxxxxxx
  • Date: Thu, 04 Jul 2002 15:18:12 EDT

>Maybe it wa a bit harsh, but then suggesting we rewrite the entire 
build
>system is pretty dramatic!

Note: *I* will rewrite it.  You don't have to worry about anything.  If 
Ingo wants to help, great.  But I can't (and wouldn't) force him to 
help, just as you can't force me to keep the current system :)

>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.

And now I can come in, look at what you have done with fresh eyes, and 
maybe clean it up.  But maybe not.  Believe me I'm very pragmatic, and 
any changes would have a good reason, not just "well this is more pure 
and clean."  Of course pure and clean usually implies easy to use and 
easy to maintain as well.

>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?!

In my opinion, I should be able to fully grasp the build system by just 
looking over the Jamfiles.  I understand Jam pretty well and am pretty 
good at figuring things out, so in theory I shouldn't need to ask 
questions.  The fact that I do totally implies that the build system 
needs to be cleaned up.  Don't you understand that?  It is one thing to 
explain things to some Jam newbie, but I don't feel I'm such a person.

>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.

Well I'm really sorry your efforts to use Jam to build the kernel were 
so unpleasant.  But seriously it is just code!  Code should not make 
you so unhappy :)  And regarding questioning, you could have asked me 
more questions about Jam, and I would have tried to help as much as I 
could.

>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".

Believe me, I more than understand that Jam and all the other build 
tools have problems.  Despite what you seem to think, I do not worship 
Jam.  But we have committed to use it as our build tool, and so in some 
sense have no choice but to use it.  Therefore I resigned myself to 
this fact and tried to find solutions for problems instead of just 
throwing up my hands and screaming "Jam sucks!!!"

>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. 

Well maybe I didn't comprehend the complexity, but I thought I did.  It 
didn't seem that hard to me.  You should have corrected me if you felt 
I was underestimating it.  Either way I was just trying to help, and as 
I recall you used some variation of my suggestion for the final 
solution (cvs log openbeos/Jamrules.)  Sorry if I hurt your 
feelings...again maybe you are taking this stuff a little too seriously 
;)

>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.

Obviously there has been some lack of communication here.  I have 
really been sort of sitting around waiting for the CVS move to happen, 
since I was under the impression that is what we were waiting for.  We 
all know Erik is working hard at it and the main constraint seems to be 
SourceForge.  To me, it makes sense to wait for this before overhauling 
the build system.  If you didn't think so you should have said 
something a while ago.

>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 I said I'm pragmatic (and yes maybe a bit of a perfectionist.)  But 
like I said above, if one makes the effort to create a more "pure" 
solution it usually pays off.  The only constraint is time, which you 
didn't really have before, but now we do.  Is it that terrible to take 
the time to create something better?

>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.

Well that is good.  Maybe the extra work required to maintain the build 
for BeOS and Linux is worth it.

Ryan Leavengood
OpenBeOS Build Team Lead

Other related posts: