I just timed the header file scan portion of a jam invokation on a local file system on HPUX, less than 1 minute.

2 minutes, 10 seonds, when everything is over NFS.

So the question would be, why does would you scan times be some much higher as to be a problem for you.

Remember, people who need to build the who tree will be waiting hours anyways.

To speed up dependency analysis without changing jam itself, you could use makedepend and process the output to create a jam.deps file in each compoment which you then include into your jam files. You could use jam itself to rebuild the dependencies, but that would definitely be a pre-invokation of jam. This would also be error prone unless jam was invoked from within a wrapper script.

(This was one of the reasons we went to jam in the first place. Please happly live with systems like this using make, but Ive been burnt too many times by builds that did not refresh their dependencies.)

If you want the makedepends like step to be automatically run within the same build of jam, then you would be looking at more extensive changes to jam.

In make0, before headers is called, call a new function, dependencies say. In dependencies you would have to a) determine is makedepend thing needs to be called. This is the worse part, but could be done easily with a perl script. b) invoke make depends with all the include "stuff" required. c) load the dependencies into jam (easy) d) CLEAR the HDRRULE on all the files for which dependencies where found (this will stop jam's traditional scanning)

I never did any of this because I'm not willing to force the jamfiles to impose that all files in a directory get built with the same C++/C/yacc/Lex (whatever) options and using the same include path. This might be the way that 99% of the sources are built, but its always that 1% that kills you.

As to users not liking writing Jamrules -- except for the semi-colon thing, the jamfiles are so easy to build that most of ours are generated automatically from our Rose Model. A rule file is rarely more complicated than.

SubDir TOP x y z ; Component y ;

ExportHdrs header.h header.h header.h ; ExportIDL file.idl ;

Library libY : file.idl file.c file.cpp ; Library localY : file.c file.cpp ;

ExportLib libY ;

ExportBin YApp ;

Server YApp : YMain.cpp ; CommonLibraries YApp ; LinkLocal YApp : localY ; LinkLibraries YAapp : libA libB libC libD ;

(just more lines and more files :)

If your users need to anything more than to declare what goes into the library or executable, what is local and what us exported, the your jamrules need to be reworked.

(I have a component called "Fake" which fakes out all of our projects build tools. This allows me to simulate a build in order to debug a new set of jamfiles without having to actually build the system.

I also have a jam.exe which I have doctored to tell me why an target is getting rebuilt. It produces too much output to be generally usable, but it has help track down bad dependency statements)

Yes, I'm from/in/born/raised (and unless somebody rescues me, probably die) in BC. I work in Richmond and live in Coquitlam. The commute is the worse part.

I've always liked Victoria -- seems much more idealic than Vancouver and suburbs.

Somedays (many days :)) I wish that somebody would offer me a job someplace warmer and DRIER. Do you know of somebody who needs a good system/software architect, knows all the buzz-words, has bad spelling, can out code even 16 year old hackers, dreams in UML, perl, java, and c++, designs embedded software or enterprise systems, usually while stuck in traffic (and builds visual basic code to turn the rose models into highly structed code templates for developers to code against) ?