[jamming] Majam - keeping jam up-to-date

[Alen Ladavac]

Hello Kai,
> - It must be faster or as fast as jam 2.5. You should measure speed using an
> automated test to make it convincing.

This would be a good asset. Perhaps Noel Llopis's build benchmark
(http://www.gamesfromwithin.com/articles/0509/000100.html) can be
useful as a basis for that kind of test.

> - It needs to retain the portable C implementation and the minimalist approach
> to including new constructs in the language or implementation.
Ditto.

> - Currently Jam is about 15kLOC, you probably want to keep it from growing
> too much, or even try to prune it back slightly.

I believe that there is no reason to add much code, as most of the
changes are more of tweaks than big additions. Where I'd find trimming
most simple would perhaps be legacy system support. But perhaps I'm
biased. It would be interesting to know whether other people need
support for VMS and similar. I'd find only NT and *nix (OSX included)
as useful as a build _host_ nowadays. Build targets can be whatever,
but I don't imagine using anything else as a host.

> - A solid regression, unit test set would be beneficial.
It would be an excellent thing to have. But I'd rather have a base to
work on and retrofit tests as we go, than wait for the tests.
Especially because the whole system is already functional. Even if
technically, it's "legacy code".

> I picked jamredux (jamr) as a pun on the original make redux.. ;-)

I like the name. Excellent pick! ;)

> That said, the P4 depot many interesting patches, like:
> http://maillist.perforce.com/pipermail/jamming/2002-January/001527.html

> Alen also has a ton of local modification, which I'm sure he is happy to share
> or I can send them over in case it's OK with him. I have also some minor
> changes in the repository above.

Sure, no problem. I'd love to get that code active outside of only our
company. That will breathe more life into it... and certainly will put
it though some more serious paces. :)

Cheers,
Alen