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

  • From: "Ryan Leavengood" <leavengood@xxxxxxxxxxxx>
  • To: openbeos-build-team@xxxxxxxxxxxxx
  • Date: Fri, 05 Jul 2002 19:19:56 EDT

>1) I also have real coding work to be done -- currently we're starting 
>to tackle the registrar and related classes, and as it is a crucial 
>part, we want to finish it as soon as possible -- and thus I would 
>really dislike, if I had to spend a big amount of time with the build 
>system.

Hmmm, sounds neat.  If you need any help, let me know. :)

But regarding the build system, I'm quite sure I can tackle it alone, 
while you can just work on a "consulting" basis (i.e. I'll ask you 
questions if I need to.)  Otherwise I don't think you need to concern 
yourself too much with it.

>2) To avoid upsetting David entirely ;-) it is a good idea to never 
get 
>the CVS repository into a state in which things don't work, i.e. the 
>changes should be happen completely unnoticable/seamless for the 
>developers. This can be done without any problems, when one person 
does 
>it alone -- change the things in the working copy until they are 
>perfect and then commit everything virtually atomically -- but may be 
a 
>bit more complicated for two persons.

Well as someone who has worked professionally as a developer for some 
number of years now, believe me that I understand that the tree in CVS 
must always be in a consistent state.  I don't consider myself to be a 
"cowboy coder" in any sense of the term, and I tend to do changes in a 
deliberate and careful way.  Especially changes of this nature.

So I fully agree with you on this point and agree that only one person 
should really be doing this.  That person will be me, and I have no 
problems with that.

>David already explained why GLOBing won't work for the kernel. I just 
>want to add another, certainly very subjective concern. I'd like to 
>warn to be careful with adding too "intelligent" mechanisms. If such a 
>thing restricts the user in specific cases or may have unwanted side 
>effects, don't implement it. The automatically collecting sources via 
>GLOB seems to be a candidate, as right from the start you had to think 
>about special cases and that for the very small benefit of not needing 
>to list the source files explicitely -- for a developer who writes 
>hundreds of lines of code into a new source file it is nothing to add 
>its name to a Jamfile.

Yes you make a good point.  I'll avoid using GLOB, but I would hope 
that you would agree all the hard-coding of $(SOURCE_GRIST) everywhere 
could probably be cleaned up.  I will at least look into that.

>Regarding the separate objects directory I totally agree with David 
and 
>Michael. Arguments were given. All larger projects I know of, separate 
>the generated files from the sources. The fact that Jam supports this 
>quite nicely should also encourage us to do this.

OK, I will keep the separate objects directory.  As you said Jam 
supports it pretty well, so I doubt it will be a problem.

Ryan Leavengood
OpenBeOS Build Team Lead

Other related posts: