Boost logo

Boost-Build :

Subject: Re: [Boost-build] disclaimer, reply, repeat myself
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2010-05-26 18:21:55

On 5/26/2010 4:32 PM, Wesley Johnson wrote:
> My intentions with this post are:

All your statements about the Boost Libraries themselves, as opposed to
the bjam and build tools, should be directed to the developer list. Not
to this list.

> I did notify Boost-build that there is a switch applied that is
> incompatible with GCC 3.3.6. I think that the compiler detection should be
> able to cope with that, so you should consider it a bug that can be fixed.
> I have gotten around that for the moment by taking it out altogether, so
> that
> is not what is holding me up.
> Knowing how it gets fixed, might actually help me though.

Did you file a bug report in trac for this? If so, could you point it
out to me.

> So sorry, but the point I was trying to make was the difficulty and hassle
> factor in installing another library
> (with its own installation problems), that only one program needs.

Indeed, which is why I've already stated that the same self-contained
simple build of bjam (note not BBv2) is required of any version of bjam,
except for development only versions. I'll avoid responding to the rest
of the library dependency stuff since I think this answers all of it.

> Among all the fixes I have had to make to get various OTHER programs and
> libraries to install, I have found over the years:
> - missing #includes
> - the wrong name on an #include
> - using the same variable name for two things
> - variable name clash with a library name
> - #include file is in a different directory
> - assumption that the library must be in /usr/lib, and it is actually in
> /usr/local/lib
> - different ideas about where /X11 libraries are
> - missing support files, like pkgconfig, when the downloaded library
> does not make them, and the user program cannot compile without them.

I think bjam has had some variation of all of those in the past too :-)
All long lived software has those problems.

This part needs a general response..

>> From your response so far, I doubt that you have any idea what C++ standard
> Boost is requiring.
> I suspect that you are using Microsoft compilers. They are known to
> result in programs dependent upon Microsoft quirks, and never seem to
> run right on other systems.
> I suspect that it is, just what-ever compiles on what-ever compiler you
> are using. That leaves the boost-community being forced to update to
> what-ever compiler you are using whenever you update your compiler.
> ((
> With some people I have to be very explicit, the next sentence does NOT say
> any of the Boost-developers are such people, but how you react will,
> so think and read it twice before you just blow-up.
> ))
> Some people are self-centered enough to think that is way the world
> should react, and I have met a few who think that the world should
> revolve around whatever tools that they use.
> ((
> I consider that I have the right to mention such people, because it may
> influence others to not be such people, and I consider that to be
> an achievement.
> ))

The Boost developer community is actually one of the few that is
required to use many compilers and their accompanying libraries. We also
strive to cover as many varied platforms/architectures we can manage.
And because a good number of the people involved in both creation of
compilers, the libraries, and platforms are in the Boost developer
community we end up finding many defects in those compilers and
libraries. And they also get a good chance of getting reported to the
vendors and fixed. You can see the wide array of compilers we actively
test in our test results

> I assume that there are at least a couple of people on the development team
> that want
> Boost-build to be a general pupose build tool.

It's not an assumption, I think we've stated it a few times ;-)

> If Boost is really meant as a general compile tool, then the reality
> is that there are many systems out there, using many different
> compilers, half of which you have never seen and cannot support
> personally.

I have seen, and used many compilers and computers in my 19 years of
programming. Going back to IBM punch-cards :-) And currently have 15
computers in my home office (not including emulators), and about 10
different operating systems and accompanying compilers. And like most
Boost developers, my main development machines have multiple compilers
and versions installed on them (for example I have 3 Xcode versions on
my mac). But yes, I can't possibly have even a small fraction of the
available compilers/platform combinations. Hence why we have volunteers
to test on other systems. Especially Noel and the large array of systems
he provides from Sandia Labs for Boost testing.

> Do you really plan on personally writing every bit of support for every odd
> compiler and system combination?

Yes, incrementally.

> Do you really want to?

Yes, incrementally.

> Do you intend to just blow-off anybody that has a system not on your list of
> acceptable combinations?

Never. But we do have priorities.

> I did ask for INSTALLATION DOCUMENTATION, other user docs are irrelvant
> to this discussion.

Sorry if I didn't see your original question regarding this.. I assumed
since other people where responding that they gave reasonable answers..
But the installation of what? Boost Libraries? Bjam? Boost Build? We
have many different possible docs depending on what you are trying to
do. And as always, being explicit with that you are attempting, i.e.
command lines and error output and test cases helps us tremendously to
answer accurately and quickly.

> Specifically, how to deal with unusal
> installation failures, and at least info on which files to look at,
> and how system and compiler dependency is coded and implemented.

If it's Bjam the sources and documentation are in the distribution under
"tools/jam". For Boost Build sources and docs are under
"tools/build/v2". The docs can be read online at
<> and
<> respectively (although
I have to update the bjam docs to the latest). I can't be more specific
than that without knowing your problems.

> Some docs on the syntax of those control files would help too.

Also documented in those I gave above. Specifically the
"tools/build/v2/tools/*.jam" files tend to have a good amount of
explanatory comments in them.

-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. -
-- rrivera/ (msn) - grafik/
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at