Date: 2001-06-26 14:13:46
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> ----- Original Message -----
> From: <williamkempf_at_h...>
> > 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
> the de-facto standard.
From what you say below this may well be true, though I'd have felt
more comfortable if the "de-facto standard" were Boost.Jam ;).
> > I realize that *the* best resolution is
> > to get Jam to adopt these changes so that we can use a "standard
> > toolset". However, if Perforce doesn't want to fold the changes
> > 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
> what David Turner has in mind, but AFAIK his code is all checked in
> Perforce public depot (like a CVS repository). That makes it
> the Jam people for inspection and easy merging.
I didn't realize that the FT extensions were checked in as
a "repository fork" of the main Jam repository.
> > If we do fork, however, I'd much prefer to bring the changes
> > into Boost, rather than using a seperate fork such as FT Jam.
> Again, I think a careful definition of terms would be useful here.
> you mean by "bring the changes totally into Boost"?
I meant that they'd be fully within the Boost CVS repository and
completely under Boost control.
> > 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
> separate copy of the source.
As do I, as evidenced by my alternative suggestions below ;).
> > 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
> to do this. It would involve learning a new revision control tool
> interested, but from everything I've heard, Perforce is a dream
> with CVS.
I didn't realize that Perforce had the Jam stuff in a public
repository. That does change my comments to some degree, though I
still would feel better if the changes were in the Boost CVS
repository. This just makes things easier on Boost members and
easier for creating distribution archives. With the source in the
Perforce repository we're going to require Boost users to learn yet
another new tool and force them to go to an external server to obtain
the sources to bootstrap a Boostified Jam.
However, the Perforce folks probably feel just as strongly about our
making changes that they may want to include in the main branch in a
totally seperate repository. There's no perfect world in any of
this. It's just that if I've been reading between the lines
correctly, Perforce isn't able or willing to fold changes into the
main source tree on any sort of acceptable time frame. :(
> > 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.
Again, I didn't realize their repository was open to the public.
> > If we forked I would think that we'd need to maintain only two
> > 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
> 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?
Feed back from users? ;) Seriously, we should be trying to both
specify the rules to the proper degree as well as writing unit tests
for them as part of the enhancements. I'm sure that along the way
we'll break some stuff since this level of design currently doesn't
exist, but at least we'll be doing our best not to and to insure it's
easier in the future.
> > 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.
A .jamrc file would solve several problems for us. It would be
trivial to customize the tool for specific build requirements this
way, and most of the configuration stuff discussed in the current
documentation would be trivial to set in a single source file. Today
I'm using a boostcfg.cmd script to set several environment variables
and a boostjam.cmd script to run jam with the proper -f switch. It
would be much nicer to put all of this into a single .jamrc.
> > All in all, I'm very interested in the Jam stuff and want to see
> > accepted into Boost ASAP. The tool is small, easy to install and
> > use, the Jamfiles are much easier to deal with than makefiles and
> > portability is much nicer. Once you start using Jam you find it
> > 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 ;-)
*laughs* Yeah, well, I'm lucky enough to be working at the higher
level of abstraction provided by you, so I'm fat, dumb and happy ;).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk