[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:30:26 EDT
>:-) Actually, I want the whole project done yesterday. ;-)
>I want R3 by tomorrow. ;-)
Hehehe, sure. As we all do :)
>I think that the 2.4 work and the looking at the content of the rules
is good.
>Sure, going and changing everything right now is kind of dumb, since
the directories
>will all get moved around and require another touch. But remember that
that is all it is -
>we aren't actually changing the structure of the source code. Just the
org of the directories.
Yes, true, I have thought of that. For example I'm pretty sure the
general structure of the kernel src will stay the same.
>I am very much a believer in the concept that the build system should
"just work".
>I (as a developer) don't want to spend a lot of time making build
stuff work. Honestly, as we
>have talked about (not sure if it was here or on the admin list), I
would love to have a build system
>that uses heuristics to figure out how to build, possibly with a
little configuration necessary if we want
>to do something complicated later.
>
>And Jam seems to be a lot of the way there, as it was 2 months ago,
for everything but the kernel.
>I looked at some of the non-kernel stuff and it was like "ok - my
target is an application called foo and
>my source files are foo.c and bar.c". That was it. And this is all it
should need to be. This .GLOB and an exception list
>sound like a really good thing. Is there a way to take that a step
further? Assume that, if there is no Jamfile, that we are
>building an application, that the name of the app is the same as the
current directory and to compile all .C and .,c files?
Well that would require some changes to the Jam C source, but I think
we could get pretty darn close to that with the kind of GLOB rule I
described and a script to automatically generate Jamfiles (simply the
first time a directory is added.) For example, a developer needs to
add a new preference app to the tree. All he needs to do is put his
source in the right place in the tree, run "genjam" (or something like
that), and a Jamfile with pretty much everything he needs (such as the
correct SubDir call) will be created. He can make a few small changes
to that file (such as setting the program name), and he will be done.
That may not be quite as automated as you would like Michael, but I
think it comes pretty close, and uses the tools we currently have at
our disposal ("genjam" could just be a shell script.)
>Now, I know that the kernel stuff is somewhat more complicated by its
nature. And some of it was a hack job
>by people like David and myself who don't know Jam (and don't want
to). ;-) I am thrilled that you guys have a passion to
>clean it up. I (and I presume David feels the same way) don't have any
particular pride or interest in the build stuff that
>we did. Whatever is cleaner and works better makes me happy. ;-)
Well as I expressed in my response to David, I don't get that
impression from him. Maybe he knows better than I since he has been
"in the trenches", but I almost get the impression that he doesn't even
want us to try to improve it. Like I said, I really do understand how
much trouble he had creating what we have now, and I wish I could have
helped out more before, but that doesn't mean we should never set about
trying to improve what we have.
I say consider the current system a "prototype", a job well done to
prove that Jam could indeed be used to build our kernel. But I hope
you all realize what is supposed to happen to prototypes, and that it
is bad if one tries to make a prototype the final project...
>As far as the seperate objects directory, I *strongly* prefer that
objects not be stored in the same directory as the code. We store
>everything inline at my "real" job and I hate it.
>The biggest reasons for that are these:
>1) When I am working in a directory, I want to see my source, not a
bunch of intermediate files that the compiler needs. Yes, I could type:
ls *.[Cch].
>2) If I want to add a directory, I have to specify which files to add,
instead of cvs -z8 add *.
>3) If I run low on HD space, I can cd to the objects dir and type rm -
rf *. Instead of something like find . -name "*.o" -exec rm {} \;
>4) The objects can be blown away easily after a build.
>5) It is just cleaner. Sorry, Ryan. ;-)
No reason to be sorry, like I said I was on the fence and just wanted
some good reasons why we use that. Though 3 and 4 can sort of be
accomplished with "jam clean", I still understand the reasoning. It
sounds good and like I said in my response to David, I will keep this
in any changes I make.
>Finally, I want to thank you guys for doing this. It isn't a glory
hound
>job, but believe me, it makes the developers lives better and it will
make our
>ultimate product a better thing. And I appreciate that.
Well I do enjoy messing around with build systems and do want to make a
better system, but again I feel as if I'm always fighting against
David. Considering this is definitely not a glory job, it is even more
surprising the difficulty I seem to encounter in trying to change the
current system...
Ryan Leavengood
OpenBeOS Build Team Lead
Other related posts:
