|
Boost : |
From: David Abrahams (abrahams_at_[hidden])
Date: 2001-06-04 13:54:09
----- Original Message -----
From: <williamkempf_at_[hidden]>
> > One think I've always done was to avoid spaces in pathnames. You
> may need to
> > embed some extra quotes.
>
> The exact environment variable command I used was:
>
> set msvcnt="c:\program files\microsoft visual studio\vc98"
>
> The quotes around the path should have been all that was needed for
> any program that supports long file names, and the case of the
> variable shouldn't have mattered. The command that finally got
> everything to work was:
>
> set MSVCNT=c:\progra~1\micros~3\vc98
>
> Do you know how tedious it is to even figure out what the short path
> name was?
I feel for you.
> > Anyway, I don't think this is the worst problem we could have. We
> have
> > agreed that we can supply prebuilt binaries for popular platforms if
> > 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 the
> same issues will exist for running jam on our jamfiles. For
> instance, the environment variable above is needed by Jam to run on
> 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.
In any case, I am aware of several issues that need to be addressed in the
jam source.
1. Need to handle unix-style paths everywhere (e.g. MacOS). Okay, one could
live without this, but it makes the Jam interface much less user-friendly.
2. Compatibility with Win95/98/ME. Someone has posted these fixes
3. The ability to do rule indirection through a variable, e.g. "x = foo ;
$(x) y : z ;" should invoke "foo y : z ;". Okay, we can also live without
that, but it makes adding new target types much more difficult.
I guess easing the bootstrap process must be another one.
BTW, once bootstrapped, I have not had any long-pathname problems with Jam.
-Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk