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

[Matthias Braun]

There is also my jamruleset here:
	http://autojam.berlios.de

I use these in several bigger open source projects (crystal-space,
netpanzer, supertux, lincity-ng). It would be a good idea to look at all
these jam alternatives, try to find out what were the problems that
motivated the fork and ask yourself if you can solve them with your fork
as well, otherwise it'll be just one more fork among many...

As far as autojam goes, it's replacing 99% of the default Jambase (I
just didn't replace the SubDir and SubInclude rules, because then you
couldn't jam from subdirectories without trouble). I did this because
several of the Jambase rules lacked features were simply buggy (in my
opinion, but for some points the jam authors disagreed). The result
should also be more consistent.

Another interesting part in autojam is the integration with autoconf,
which is mainly some shell scripts and additional autoconf macros to
make the configure scripts output a Jamconfig file which includes all
the options and settings configure determined. Having something to check
and adapt for the users build environments is vital for open source
projects IMO, and most build tools don't provide the necessary tools for
this. So we need some sort of integration with autoconf (so far I
haven't seen a viable alternative to autoconf unfortunately).

Greetings,
	Matze

Am Montag, den 31.07.2006, 14:48 +0100 schrieb Kai Backman:
> Hi,
> 
> First I must confess that I've been planning a similar integration for a while
> so I'm strongly biased towards more development activity .. :-)
> 
>   There are already several "new" jams (ftjam, boost jam, kjam etc) around that
> haven't replaced the current Perforce codeline. These are the details I think
> are important in case you want a new version widely used:
> 
> - It must be faster or as fast as jam 2.5. You should measure speed using an
> automated test to make it convincing.
> 
> - It needs to retain the portable C implementation and the minimalist approach
> to including new constructs in the language or implementation.
> 
> - Currently Jam is about 15kLOC, you probably want to keep it from growing
> too much, or even try to prune it back slightly.
> 
> - A solid regression, unit test set would be beneficial.
> 
> Here is a list of resources I've allocated. In case we can agree on the vision,
> we should pool effort:
> 
> Subversion repository and issue tracker (Google Code hosting):
> http://jamredux.googlecode.com/svn/trunk
> http://code.google.com/p/jamredux/
> 
> Webspace and domain on VPS server (nothing on the server yet):
> www.jamredux.org
> 
> I picked jamredux (jamr) as a pun on the original make redux.. ;-)
> 
> On 7/31/06, Craig Allsop <cjamallsop at gmail.com> wrote:
> > Why wouldn't one use perforce's public depot for this job - this is where
> > most of the existing patches have been placed?
> 
> I think I'm siding with Groleo in using Subversion instead of P4. Because of
> svn's copy-modify-merge style of work it is more suited for clients not having
> a stable network connection to the repository. My personal experience,
> having worked with both P4 and SVN in a distributed team, was that SVN had
> less downtime due to network issues.
> 
> 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.
> 
> @Groleo: I checked out your SF repos and noticed you don't follow the
> canonical trunk/tags/branches setup? How are you planning on doing
> release branches and tagging?
> 
> Take care,
> 
> Kai
>