Re: [boost] [1.36.0] Getting Started changes (ticket #1744 plus other fixes)

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-08-11 13:09:40

David Abrahams wrote:
>>>> * Section 5.2.4, Invoke bjam, both Windows and Unix Variants: needs to
>>>> say what library variants (static/dynamic, debug/release,
>>>> multi-threaded/not) are build by default.
>>>>
>>>> [Rationale: (1) It is too late to change the default behavior for
>>>> 1.36.0. (2) The worst problem with the new defaults isn't the specific
>>>> choices, but that those choices aren't documented, 
>>> I'm not so sure.  While they may have other benefits, the new defaults
>>> are going to make the getting started instructions more complicated.
>> For unix-variants, I added instructions for building all variants, in
>> addition to the defaults. That did add a bit more wording, but not
>> enough to be worrisome IMO.
> 
> Yeah, but I bet your instructions don't work for MacOS or AIX (which use
> different symbols for the library path), or even on Linux if you're a
> user who doesn't have write permission on /usr and has to use --prefix=
> to install elsewhere (since you didn't mention LD_LIBRARY_PATH in your
> instructions).  That's where at least some of the complication is going
> to come from.

AFAIK, I don't have write permission for /usr. Where does /usr enter 
into the current instructions?
> 
> Honestly, I don't understand why we don't just expand the installed
> defaults to include static libraries so the existing instructions work.

In my tests on both Windows and Linux, static libraries were built, 
although perhaps not the set some users expect.

> If you're worried about destabilizing the release because static
> libraries don't build successfully somewhere, I have to ask you: would
> it really be acceptable to release Boost like that in the first place?

It is coming up on two weeks past the target release date. I assume 
those who want more than the default will simply do a "complete" build.

> I worked *extremely* hard to make sure that the instructions as they now
> stand will *not* cause people to run into stupid issues that prevent
> them from getting started with Boost or decide that Boost is hard to
> use, and it's very frustrating to see the potential problems taken so
> lightly.

I agree. This was the straw that broke the camel's back as far as I'm 
concerned. I've lost all interest in supporting the current Boost.Build 
system and look forward to moving one hundred percent to something 
better, more responsive to user needs, and less likely to break the 
release process at unexpected moments.

> I don't think adjusting the guide to use dynamic libraries is
> something you can do at the last minute and not cause problems for our
> users.
> 
>>>> and (3) it needs to be crystal clear how to build the full set.]
>>> Yeah, but that's not nearly enough.  We also need to make sure that the
>>> instructions for building the examples in the getting started guide are
>>> all correct, including all their command-line variations, for all
>>> platforms, and don't leave out "silly" details like the potential need
>>> to set LD_LIBRARY_PATH (or whatever other platform-specific environment
>>> variable may be required) now that we are no longer building static
>>> libraries by default.  Testing these instructions for all platforms is a
>>> large job, and I'm not in a position to do it by myself.
>> I've tested the two unix-variants build examples on Linux. I'm now
>> starting to do similar tests on Windows. That's not as good as testing
>> all combinations, but at least we know the given examples do in fact
>> work.
> 
> In certain environments on certain platforms.  Er, one environment on
> one platform.
> 
>>> In case anyone's wondering why I didn't "simply" go ahead and update
>>> the GSG when I discovered that the default build choices had broken
>>> it, that's why.
>> Understood.
> 
> No offense intended, but I'm not so sure.
> 
>>>> * Section 5.2.4, Invoke bjam, both Windows and Unix Variants: after
>>>> the current contents, needs to give the exact command line for
>>>> building all library variants.
>>>>
>>>> [Rationale: resolves (3) in prior item.]
>>>>
>>>> Since Dave is on vacation, I'm not sure he will be able to make these
>>>> changes. If he can't make them, I'll give it a try.
>>>  I'm somewhat available, but like I said, the changes to the
>>> defaults
>>> have made things a lot more problematic than they used to be, so we'll
>>> need to get lots of people to put attention on this.
>> Yes. I hope others will read "Getting Started", and actually try the
>> instructions on their systems ASAP.
> 
> I think if you want to have confidence about the result, you'll need to
> be a lot more aggressive about looking for pitfalls than you have been
> so far.

Sorry, we are out of time. It is as simple as that. Anyone concerned 
that this will cause a release to be shipped that isn't good enough 
should start spending more time *early* in the release process looking 
for gremlins.

--Beman