Re: [Boost-build] disclaimer, reply, repeat myself

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 
<http://www.boost.org/development/tests/trunk/developer/summary.html>.

> 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 
<http://www.boost.org/doc/tools/jam/index.html> and 
<http://www.boost.org/doc/tools/build/index.html> 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. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail