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

From: williamkempf_at_[hidden]
Date: 2001-06-26 12:11:10

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "David Turner" <david.turner_at_f...>
> 
> 
> > Hello,
> >
> >   I'd like to inform you that I've just released a new version
> >   of "ftjam", the improved version of Jam that runs under
> >   Windows 9x (originally written for FreeType, but fully
> >   bacwkwards compatible with Jam 2.3.1).
> >
> >   This new release fixes a few annoying things in the original
> >   Makefile/Jamfile (they assumed that the current directory was
> >   in the path, which rarely happens on secure Unix systems).
> >
> >   This new release also supports indirect rule invocation, as in
> >
> >       [ $(RULE)  params ]
> >
> >   which calls the rule whose name is given by the expansion
> >   of the RULE variable. This should be of great value to the
> >   Boost community and to other Jam hackers..
> 
> 
> Fabulous! Does it also work without the square brackets if you 
don't need a
> return value?
> 
>     $(RULE) params ;
> 
> Another moderately-high priority for me, and one I've just 
discovered, is to
> open up the MAXLINE constant for Windows NT. I am not interested in
> supporting NT3.5 (sorry!) and it is fairly easy to come up with a 
link
> command line that exceeds the 996 characters allocated by the 
default Jam on
> NT. If you don't feel comfortable about folding that change into 
FTJam, I
> would be "forced" to make the modification myself, resulting in 
(IMO) a very
> silly code fork.

Does all of this traffic indicate that Boost should adopt FT Jam 
instead of the official 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.  
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.

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.
2)  We can make bug fixes and other changes much faster than they 
will be incorporated into the "official" Jam tool.
3)  We can manage changes easily through CVS allowing a broader 
approach to development than what Perforce currently offers.

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.

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 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.

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

Bill Kempf