1. Why white space is the only delimiter in jam?

It was a _mistake_. At the time ('93) whitespace in file names was very uncommon, but one platform critical to us was VMS. You know, $sys$device:[user.jam]parse.c;3 VMS.

I still think sparse quoting makes Jamfiles easy to read, but requiring whitespace around the ; is very error prone.

If there is a compatible way of changing this without a "mode bit," I'm all ears.

2. Why not cache header file scans to improve speed?

a. Because it is not that much speed (YMMV).

b. Because caching is more complex and less reliable.

c. Because I hated build tool turds.

Those were the reasons when Jam was written, and they still stand fairly well now. Caching is more important for Make, which must re-evaluate header dependencies for every subdirectory, rather than just once for the whole tree with Jam.

3. Why no shell invocations during parsing? I want "x = `ls` ; "

Jam was born in a dirty environment, where "mkmf" scripts scrounged up all sorts of garbage and built, well, whatever came out. In reaction to this squalor, Jam insisted that how to build the source is part of the source and not part of the build. The goal was to ensure that a second "jam" invocation would do a deterministic _nothing_.

This asceticism could probably be relaxed now, but I doubt portability madmen like us would use it: native OS tools vary widely ("think different"), and if you have to build a tool to drive Jam you've lost a little sanity. What builds the build tools?

4. Why doesn't Jam incorporate all these neat ideas on the jamming mailing list?

We are trying. Jam has been a bit of a stepchild here at Perforce, but (as has been mentioned) we have hired an open source engineer to act as Jam curator.

That doesn't mean it will take on all changes. One of Jam's virtues is leanness, both in code and in concepts, and we will continue to guard that. There are, however, egregious gaps in functionality (like regexp handling and access to target-specific variables) and porting coverage that are certain to be filled.

Christopher