[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 14:06:02 EDT
>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:
