I am very much in agreement with Ingo here. We want the system to be simple to use, but not necessarily doing everything for us. I think the BeOS makefile system is a beautiful example of that (esp. since I don't feel like I'm actually using make ;), so that might be a good place to look in order to see what level of abstraction to shoot for. I, for one, don't mind listing my source files, app/lib name, libraries to link to, etc., explicitly -- I don't want to have to write rules in order to get most things done. One thing I want to throw out there is that I'm very unenthusiastic about the idea of having a configuration script that needs running. This is exactly the sort of thing I would like to see built in. The Be makefile system builds projects correctly on x86 and PPC without any work on the users part. Likewise, I think our system should deal with platform specific nitty-gritty without the user having to do *anything*. I want to checkout source and run jam -- that's it. My $0.02, e >> >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 >system. >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 Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves. -William Pitt, British prime-minister (1759-1806)