[Boost-build] disclaimer, reply, repeat myself

Subject: [Boost-build] disclaimer, reply, repeat myself
From: Wesley Johnson (johnson2412_at_[hidden])
Date: 2010-05-26 17:32:40

This is long enough, so I try to keep it very terse, and avoid repeating
more platitudes.

I work on two free-software projects myself which mandate compatibilty
with old data files and C compilers.  I recently fixed one to restore
compatibility with an older library release, so I do know what effort is
required.

My intentions with this post are:
1. Correct mis-statements about my last message. It was about the
discussion concerning next Boost library requirements, and how
disagreeable it is to install a tool with such library requirements.
Some people are off on some flame of thier own devising, please read more
carefully.

2. I am disappointed that older compiler compatibility was lost.
I await any response that would indicate that compatibility will
be restored.
I hope that it would be entered as a bug to be fixed (older compilers
incompatible with switch concerning precompiled headers).

3. The hope that some information of use in fixing (2) would possibly come
forth, if even by some accident.

4. I really hate replies that quote the entire post, and then insert
nasty comments at points they wish to attack.  Such replies never, ever,
address the actual question asked.  So, I am forced to repeat myself.

My previous message is being mis-stated.
I never asked in either message that YOU (unspecified person who replied)
fix
Boost to compile on GCC 3.3.6.
If you think I did, then please do not reply, I am not interested.
If you think that I am somehow denegrating Boost by MY (not YOU) trying to
get it compile on Linux 2.4.31 using GCC 3.3.6, then please just dump some
flame retardant on yourself.

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.

My last message was:
((
< paragraph explaining my situation (which did not ask you to fix it!) >

< sentence explaining that it was relevant to the discussion I
  observed in the boost-digest >

< my contribution to that discussion on boost rewrite and using
external libraries (which was - advise against being dependent upon external
libraries -- ) >
))

I have been fighting with several installations (which you are NOT being
asked to fix either), one of which required Lua, and one required a couple
Boost libraries, (and maybe its the same one).  After fighting with these
off an on for months, I do not clearly remember which required which.
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.

So, you say it wasn't Boost that required Lua, .. okay.  I was
discussing the problems of having Boost require Lua, and why it was a
bad idea.  In the Boost-digest someone brought up Lua and considered using
it for Boost-build, and I was replying to that discussion.

Some programs seem to make a point of requiring some 2 or 3 odd
libraries that I have never encountered before.  Some of them I cannot
even find on the internet anymore, the source site has disappeared.
So if you actually become dependent upon some library, such that it is
required to build your tools, you need to seriously consider hosting it on
YOUR site !!
Do not make the user go searching for it.
You probably will only be compatible with one specific version
of it anyway, so put that version that you are using on YOUR website.

As to using GCC 3.3.6 and the question that I did ask concerning what
standard of C++ was being used.
I note that one reply said that you only need C.
Another reply said that GCC 3.3.6 only half supports C++ (which is not
true) and that was the problem.

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.

When I mention that I am using GCC 3.3.6, and then I get the knee-jerk
response
that it MUST be the problem, I am dubious.  It saves so many people from
having to think at all about the questions actually asked, that I
suspect those particular people just use it as an easy excuse to blow-off
the
tough questions that they don't want to answer.
My experience indicates that it is more likely something other than GCC
3.3.6.

I actually do not know of any C++ standard compilation that is significantly
different between GCC 3.3.6 and newer compilers.  That is why I ask
what C++ standard you are writing to, so I can figure out if there is
anything along that line that I could change.

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

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.

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.

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

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

I did ask for INSTALLATION DOCUMENTATION, other user docs are irrelvant
to this discussion.  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.

I did ask for:  "a big red arrow to where it is", so that I can FIX IT
MYSELF.

What does the person who argued against
documenting the control files, have against my fixing problems on my own
system,
that you deliberatly fight against it and consider that it would be a bad
idea to let users know where those files are and how to fix them.
It sounds like a control-freak who cannot stand to have someone touch
his private files.  So to be explicit again, if you are not a
control-freak, then how about some INSTALL DOCS or some info on where
in all those files a user programmer, or first time installer, would look to
fix a compiler version
dependency or other problem.

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

Wesley D. Johnson