Re: Directory Structure

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-12-18 10:21:32

--- In boost_at_[hidden], "John (EBo) David" <ebo_at_e...> wrote:
> Jeff Garland wrote:
> > 
> > John Maddock wrote:
> > > One other point that came across from a point made by Beman in 
a private
> > > email on another subject - some commercial users will simply 
not use boost
> > > if it relies on any tools not installed by default on the target
> > > platform - that means no python among other things - sorry :-(
> > 
> > This is a difficult standard to impose on boost.  Aside from the 
various
> > Unix flavors, I don't know of a single platform used for 
development that
> > doesn't require the installation of tools on top of the 
platform.  To
> > develop C++ on Windows I have to install Visual C++ or some other 
Windows
> > development environment.  If I am doing commercial development, I 
will need
> > to install a design tool, configuration management tool, bug 
reporting tool,
> > project tracking tool, above and beyond the compiler.
> 
> I may be misreading this but I think you missed a subtle point.  The
> installation tools (make, install_shield, ...) useually *are* part 
of
> the base install.
> 
> <begin rant>
> 
> This one is closer to home maybe.  I don't know Python.  I do 
however
> know Perl.  Now I know that there has been some sort of holy war 
over
> Python/Perl for YEARS.  I've never followed the details and frankly 
I am
> not much interested.  On the otherhand, if I have to install yet 
another
> language to even compile and install a set of C++ libraries for C++
> programs I personally am going to find it anoying.

Most people would agree with you, however...

>  Now if this ScCons
> (or whatever it was called) is *so* much better than autoconfig 
(which
> generates a portable sh script), automake, etc. then I'll take the 
time
> to learn and switch.  But I for one am going to be a bit of a hard
> sell...  How is it *so* much better?

A *lot* of platforms don't have autoconfig, automake, etc.  So it's 
fine if the build process uses those because *you* have them on *nix 
systems?  Your *nix biased is showing.

Face it, there is *NOT* a standard way of doing this that's portable 
to all (or even most) platforms.  I believe ScCons is going to 
attempt to do this while remaining simple (autoconfig is not, and 
requires installation of an entire shell! to work on Windows 
platforms, for example).  I'll fight tooth and nail against such a 
heavily biased *nix solution, more so than I would fight against the 
need to install a scripting language, which has a smaller impact on 
my environment.  I'd prefer a non-general-language solution, such as 
ScCons, but I'll take Python or Perl over autoconfig.  Sorry.

> In the *NIX world, Borne Shell (sh) as I recall is the defacto 
standard
> that is installed on every implementation, and csh is a close 
second. 
> In the dos world, you still have batch files (.bat), etc...  Yea 
they
> are not pretty, but they basically work everywhere.  What I would 
love
> to see is ScCons do whatever magic that it need using
> Python/Perl/whatever then produce sh, csh, bat, ... so to build and
> install does not require to much extra, but then I am sure I am a
> manority here and probably just being some old fuddyduddy...

This requires multiple distributions.  We'd be better off just hand 
coding such scripts, IMHO.  I'd prefer a truly portable build system, 
even if this means installation of a new tool.  I think most people 
would agree.
 
> <end rant>

> > However, there are some commercial organizations that won't use 
boost if
> > they have to COMPILE it. 
> 
> That is part of what platform specific binaries are made for.

I don't think Boost is interested in going into the job of producing 
and maintaining multiple distributions this way.  It's too much 
work.  I would expect in the future to see other sites maintaining 
individual binary distributions for specific targets, however.
 
> > In addition, some organizations have policies
> > against using libraries if they can't PAY someone for support.
> 
> That is part of what survice oriented companies that package, ship, 
and
> support public domain produces (Like RedHad, SuSE, etc.) are for...

They have *nix bigotry problems, generally.  Boost has more noble 
goals, in this regard.  I'm not sure a service oriented company would 
be interested in providing Boost support.

Bill Kempf