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

  • From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
  • To: openbeos-build-team@xxxxxxxxxxxxx
  • Date: Fri, 05 Jul 2002 02:05:05 CEST (+0200)

> >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 :)

Yes, I think a well designed build system is important and I'm willing 
to help you to achieve that goal. But please consider these two points:
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 
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.

Regarding some points in your original mail:

> 3. [...]
> Since we are using Jam 2.4 now, which has 
> the GLOB rule, we could just use KernelObjects [ GLOB . *.c ] ; in 
> each 
> kernel sub-directory.  Or, if we also need the $(SOURCE_GRIST) 
> appended 
> to each source (which must be the case given the current Jamfiles), 
> we 
> could write a rule to do this using GLOB and a for loop, so that 
> again 
> we have avoided the hard-coding.  I say if we can use the power of 
> Jam 
> to make our build files simpler, we should.

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.

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.

The other points in your mail (unless I missed one, what me well be as 
I'm pretty tired ;-) are very good.

CU, Ingo

Other related posts: