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

From: David Abrahams (dave_at_[hidden])
Date: 2008-08-11 13:58:06

on Mon Aug 11 2008, Beman Dawes <bdawes-AT-acm.org> wrote:

> 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?

If you use "./configure; make; make install" as the instructions
suggest, the libraries will get installed into /usr/local/lib, which is
in the default dynamic library search path on many systems.  People who
don't have write permission on these directories need to use ./configure
--prefix=/some/writable/directory, and that directory is typically not
in the default dynamic library search path... which won't matter if you
are linking with static libraries.  But given the instructions, it will
show up with dynamic libraries when you try to run your program.  That's
one reason the instructions used static libs.

>> 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,

That's not what http://svn.boost.org/trac/boost/ticket/1744 indicates
would happen.  Did someone change the default behavior without updating
the ticket?  If so, this whole issue might have gone away.

> 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.

Beman, that's not the point. Yes, they will, but first they'll have to
discover that the reason their "Getting Started" experience has failed
due to not having the right libraries available.

>> 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'm sorry, but while I agree that switching build systems is probably
the best thing for Boost, I don't think what's happening here has
anything at all to do with technology.  This problem is entirely a human
one: someone (or some of us) decided to change which variants of Boost
were being installed by default and didn't consider the impact on the
GSG.  This problem could just as easily have happened with any other
build system.

>> 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.

I'm not sure how to take this.  Are you suggesting that I should have
spent more time early in the process trying to discover that someone
else's changes broke my documentation?  In fact, AFAICT the GSG was
broken by these changes for 1.35, and I didn't really even understand
what was going on for a while.  Just look at the initial comments in
http://svn.boost.org/trac/boost/ticket/1744.  Please, I'm not offended
by the idea, but if you think I should be doing something differently to
prevent this problem in the future, I would like to know precisely what
that is.

Thanks,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com