Travis Geiselbrecht wrote: > > Be did not use JAM. Be had a recursive makefile system that was recently > rewritten to be a single flat makefile with included sub-makefiles. Ah. I stand corrected. > I used jam at a company I worked at for a couple of weeks after Be and I > hated it. It's pretty good for little projects, but it hides a lot of > the customization ability of make and was not very intuitive for complex Make can hardly be considered "intuitive" for *anything*, but I get what you're saying. > tasks. On top of that it had some cute messages it would print when > thinking that really pissed me off. If they were pissing you off, the messages must not have been cute enough. ;) > Anyway, I was not impressed. But it could have been that this company > was just not using it right. Then it looks like I need to do more research. Maybe I'll spend some time this weekend converting my other gigano project to JAM and see how that goes ... we've found make + build scripts to be usable, but hardly optimal. e > > The IK Team has been toying with the idea of using JAM > > instead of make. > > Here's a lovely informational URL: > > > http://www.perforce.com/jam/jam.html > > One of the attractive features is that JAM is supposed to be quite easy > to use for large projects: "Jam/MR can build large projects spread > across many directories in one pass, without recursing, tracking the > relationships among all files." > > Those who wish to get the full-bore overview should see (apparently a > little dated): > > http://www.perforce.com/jam/doc/jam.paper.html > > Anyway, seems like a good time to toss the idea out to the group at > large. =) I recall someone mentioning that Be was using JAM instead of > make (Cedric??). Perforce also uses it to manage their own build > process -- which, with all the platforms they support, has got to be > pretty crazy. > > e > > Duncan Wilcox wrote: > > > > > Hello. My name is Aaron Davis. I am now the build meister for > > > OpenBeOS. Michael told me my first assignment was to investigate > > > what everyone thought of as a good source tree and then make > > > something that everyone can live with. So thats what i'm doing. Feel > > > > free to e-mail me suggestions to my address > > > (iceman@xxxxxxxxxxxx) or to the list. Any input would help me revise > the > > > current source tree. Thanks. > > > > http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html > > > > It's quite hard to design a non-recursive makefile tree that is > > flexible and powerful, but it really pays off. > > > > Duncan