[boost] Re: 1.30.0->1.30.2: no more thread support for Linux?

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-27 18:23:25

Ross Smith <rosss_at_[hidden]> writes:

> There's been this massive trap lurking in Boost all this time, and
> you knew about it all along and didn't tell us. 

Wrong.  Speaking for myself, I knew about the behavior, but never
realized it was a trap.  It's inappropriate for you to treat
well-meaning and hardworking volunteers as though they're malicious or
indifferent.  We're not perfect, so we'll occasionally make a
mistake (**).  Back off Jack.

> And you wonder why people are pissed off??!!

No, I only know of one person who's pissed about this, and I don't
wonder at all why.  He's historically prone to inappropriately heated
outrage.

>>>All I asked was how to set the multithreaded option.
>>
>> That question wasn't clear from your posting.  As far as I could tell
>> you were asking how to "just run bjam with no options and get the libs
>> built with thread support".  Maybe if you applied a little less heat
>> it would be easier to help you.  Sarcastic rhetoric may have hurt the
>> comprehensibility of your request.
>
> It wasn't intended to be sarcastic, apart from the bit about
> clairvoyance. The immediately preceding paragraph said "The others
> will not, unless <threading>multi has been placed in their
> default-build settings", so I thought it would be clear that that
> was what I was asking how to do.

I'm still having trouble parsing what you wrote.  What does the second
"that" refer to?  If I squint hard I can guess you might be referring
to "<threading>multi has been placed in their default-build settings",
though it still doesn't fit grammatically.  Maybe if you calm down a
bit you'll be able to express yourself clearly enough for us to help
you quickly and without all this static.

>> http://www.boost.org/tools/build/build_system.htm documents how to
>> set the build request on the command-line, and you can in fact find a
>> mention of <threading>multi in there if you dig hard enough.
>
> No, it only mentions threading in connection with writing new
> jamfiles.  There's nothing about how to set it on the command
> line. Presumably somebody familiar with Jam could deduce one from
> the other

Yes, I think it's pretty straightforward to guess that we didn't limit
the properties you can set on the command-line to just the ones used
in the command-line examples.

> , but I hope you don't expect everyone who wants to use
> Boost to learn about Jam.

I do expect anyone who is going to build with Jam to learn a little
bit about it.  That is why we publish documentation, after all
(incomplete though it may be).

> There's also no hint in there that the <threading>multi option has
> anything to do with Boost; it's in the context of a hypothetical
> project unrelated to Boost. 

Well, it is the Boost build system, after all.

> So even somebody who did investigate how to use the build system
> would have had no reason to suspect that <threading>multi had
> anything to do with Boost. 

Actually, if you investigated how to use the build system you'd soon
find out that properties are not made meaningful by projects, but by
the build system itself.  If <threading>multi can be used with project
A, it can also be used with project B (provided project B is
compatible with the compiler's multithreaded build flags).

> The option is not mentioned anywhere else in the
> documentation. Neither are any other options, for that matter.

It's true.  The build system is underdocumented.

> And I still think my third question -- how many other gotchas are in
> there? -- is a perfectly reasonable one. 

Only if you believe we know about all the gotchas, realize they're
gotchas, and are keeping them a secret -- in other words, only if you
think we're malicious and/or indifferent.

> If you want me to spell it out in more detail: What other
> undocumented build options are there that might affect the library's
> behaviour?

Oh, that's a much more reasonable question.  You can find all of the
feature definitions by doing

   grep "feature " *.jam

in the tools/build directory.  Unfortunately, the meaning of these
features is often not documented, but the names are designed to make
the meanings apparent.  Also, not all toolsets respond to all
features; you generally have to examine the "flags" rules in a
toolset file to see how a feature might affect a compilation.  If you
have specific questions about any of these, just ask.

See how helpful I can be?

(**) I think I want to hear one or two other opinions before we decide
this decision was wrong.  People seemed pretty well convinced it was
right once upon a time.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com