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