From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-06-26 12:51:07
----- Original Message -----
> Does all of this traffic indicate that Boost should adopt FT Jam
> instead of the official Jam?
I am beginning to think that may be best. A project "lives" where it is most
energetically developed. I'm not sure about this, but that might make FTJam
the de-facto standard.
> I realize that *the* best resolution is
> to get Jam to adopt these changes so that we can use a "standard Jam
> toolset". However, if Perforce doesn't want to fold the changes into
> the "official" Jam tool then we should definately consider a fork.
I think we need to carefully define what is meant by "fork". I'm not sure
what David Turner has in mind, but AFAIK his code is all checked in to the
Perforce public depot (like a CVS repository). That makes it available to
the Jam people for inspection and easy merging.
> If we do fork, however, I'd much prefer to bring the changes totally
> into Boost, rather than using a seperate fork such as FT Jam.
Again, I think a careful definition of terms would be useful here. What do
you mean by "bring the changes totally into Boost"?
> There are definate advantages to a Boost fork of Jam:
> 1) We can add Boost specific concepts, such as
> compiling "allyourbase.jam" into the tool.
I think this could be handled other ways than maintaining a completely
separate copy of the source.
> 2) We can make bug fixes and other changes much faster than they
> will be incorporated into the "official" Jam tool.
If our code is hosted at the perforce public depot, we would still be able
to do this. It would involve learning a new revision control tool for those
interested, but from everything I've heard, Perforce is a dream compared
> 3) We can manage changes easily through CVS allowing a broader
> approach to development than what Perforce currently offers.
I'm not sure that's true. Perforce does offer "group access" to areas of the
public depot, upon request.
> If we forked I would think that we'd need to maintain only two major
> rules for backwards (and future) compatibility: all command line
> switches must operate identically to how the official Jam tool
> behaves, and Jamfile rules/code must be a pure superset of that
> supported by the official Jam.
I like that as a policy. A small problem is that many of the Jambase rules
are somewhat underspecified, and there are no unit tests for them. So if we
want to refactor some code or add a feature to an existing Jam rule, how do
we know if we've broken it?
> So the changes discussed so far are mostly safe. Support for Win9x
> won't break anything. The addition of indirect rule invocation will
> also not break anything (though Jamfiles that use it will not work
> with the official tool). The lengthening of the command line is also
> safe (I'm not familiar enough with Jam, but if the length is queried
> by Jamfiles I'd vote for reading OS info on NT to return the shorter
> line length on NT 3.5).
The source is not structured for that right now, since MAXLINE is a macro,
but I agree that your approach would be more principled.
> The only change that we want that would break stuff is to roll our
> allyourbase.jam into the tool. Dave Abrahams suggested that users
> could still use -f to specify the old Jambase stuff, but that just
> reverses the problem. There are alternative changes that I'd
> consider better. For example, a -boost switch to use the Boost
> specific Jambase stuff and/or a .jamrc file similar to the .cvsrc
> file for CVS.
I like that idea very much.
> All in all, I'm very interested in the Jam stuff and want to see it
> accepted into Boost ASAP. The tool is small, easy to install and
> use, the Jamfiles are much easier to deal with than makefiles and the
> portability is much nicer. Once you start using Jam you find it to
> be addictive
> (though I suppose building the base rules may lead you
> to some things that are hard to accomplish with the Jam language).
you have a talent for understatement ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk