Date: 2001-06-04 14:02:21
--- In boost_at_y..., "David Abrahams" <abrahams_at_m...> wrote:
> ----- Original Message -----
> From: <williamkempf_at_h...>
> > Do you know how tedious it is to even figure out what the short
> > name was?
> I feel for you.
The SUBST "hack" would have solved this, but not everyone's going to
have a free drive letter to use for this. :(
> > > Anyway, I don't think this is the worst problem we could have.
> > have
> > > agreed that we can supply prebuilt binaries for popular
> > > neccessary. I'm confident that we can improve the bootstrap
> > process, too, if
> > > we feel it's important.
> > My fear is that if these issues exist for bootstrapping jam that
> > same issues will exist for running jam on our jamfiles. For
> > instance, the environment variable above is needed by Jam to run
> > NT/2000 as near as I can tell for Jam to figure out the compiler
> > being used.
> We replace the Jambase with our own, which doesn't insist on these
> variables, fortunately.
I just realized this, and that's a very good thing! :)
> In any case, I am aware of several issues that need to be addressed
> jam source.
> 1. Need to handle unix-style paths everywhere (e.g. MacOS). Okay,
> live without this, but it makes the Jam interface much less user-
> 2. Compatibility with Win95/98/ME. Someone has posted these fixes
I wondered about that one.
> 3. The ability to do rule indirection through a variable, e.g. "x =
> $(x) y : z ;" should invoke "foo y : z ;". Okay, we can also live
> that, but it makes adding new target types much more difficult.
> I guess easing the bootstrap process must be another one.
Yes, though a good set of directions would be enough. As much of a
pain as it was to deciphere the short path, if explicit directions
had been given on how to bootstrap Jam I still could have done so in
under 5 minutes. As it was, it was more like 45 minutes because of
the trial and error involved. Frankly, some users would probably
never figure it out.
> BTW, once bootstrapped, I have not had any long-pathname problems
I've just tested your example Jam files and find this to be the case
for me as well. It looks promising. What I'd like to do is write a
Jamfile for Boost.Threads as a real world example of the Boost.Build
system, but I frankly have no idea what I'm getting myself into
there. I may send you some (private) e-mails asking questions if I
get stuck. However, I think Boost.Threads is a complicated enough
build system to be a good trial, while not being too large to manage
yet, and since it's not in CVS it's safe from effecting any Boost
releases. Any thoughts on this?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk