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
> 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
> 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk