>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. I would *like* to not have to do anything at all. This seems like it would be pretty easy, from a coding perspective - if open() fails on "Jamfile", use this default one... But if that is too tough, than forget it. >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. I have to agree, here. If the issue is that we want to build jam, I would say that a simple script that builds it should be OK. It isn't like there are going to be partial builds lying around or anything... The only thing that I would like to see, someday, is the ability to have something in the build detect your machine configuration and give the option to do an optimized build for your architecture. >My $0.02, > >e