Re: [jamming] new release of "FT Jam"

From: williamkempf_at_[hidden]
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 
make FTJam
> 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 
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.

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 
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"?

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 
completely
> 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 
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
> 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 
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?

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 
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
> 
> :-)

*big grin*

> > (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 ;).

Bill Kempf