Re: [jamboost] Re: [boost] Release plans [was: Maintenance release?]

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-05-05 21:53:11

----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
To: <jamboost_at_[hidden]>
Sent: Sunday, May 05, 2002 9:43 PM
Subject: Re: [jamboost] Re: [boost] Release plans [was: Maintenance
release?]

> On 2002-05-05 at 05:52 PM, david.abrahams_at_[hidden] (David Abrahams) wrote:
>
> >In light of the proposed release schedule below, I think we should
> >consider what needs to be done to get Boost.Build (v1) in shape. I
> >realize we have placed a moratorium on v1 development, but I think it
> >would be appropriate to make an exception for some ease-of-use fixes.
> >
> >My list of what's important:
> >
> >1. Change all configuration variables representing paths to names
> >which end in "_PATH". This eliminates "spaces in pathnames" problems
> >since Jam won't split these except at path separators (':' on *nix,
> >';' on windows).
> >
> >2. Set these variables as neccessary from variables with the old names
> >for backwards-compatibility
> >
> >3. Add comments about how to configure the toolset (see gcc-tools.jam).
> >
> >4. When configuration is detectably wrong, print a helpful message
> >about how to configure the toolset (see msvc-stlport-tools.jam). This
> >should be extended to take advantage of the GLOB rule if it is
> >defined, though we have to be careful to release precompiled jams
> >which support new features before we do anything which requires
> >them. The GLOB rule can be used to look for the compiler in the PATH,
> >for example.
> >
> >5. Possible low-cost replacement for 3&4: implement a
> > --help-<toolset-name> option for each toolset which dumps
> > configuration instructions.
> >
> >Thoughts?
>
> To put it bluntly... I think #1, #2, & #4 are a bad idea... Currently V1
is
> working and hasn't shown major problems for weeks. So I think it would be
> dangerous to start changing things that will definately introduce bugs.
And
> this for a slight benefit of making it easier to use/setup which we
agreed
> is something we would postpone until V2.

The benefit is that the deluge of support requests which are sucking away
my time will disappear. In general, though, I like the way you're thinking:
let's not get involved in adding complicated code which will just cause
problems.

>
> As for #3 & #5... Like I've mentioned before it's documentation that will
> really helps the users at this point. And I aggree that it's needed to
> alleviate the number of questions that always come up. Documenting the
> individual toolsets is certainly good idea. But adding more jam code to
put
> in a help system (even a minimal one) is more trouble than it's worth.
I'd
> rather we put that same documentation into some, more user friendly, HTML
> file(s).

OK, I agree. Let's do that, then.
I suggest we make only one code change:

Use the :J=" " trick to reconstitute single-item environment variables
which may contain spaces. This applies especially to toolset config
variables used to build Jam itself.

The spaces in path names issue is easily solved and has been a major
problem for users.

-Dave