Re: [boost] Re: Directory Structure

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-12-17 06:55:57

>Let me restate the idea:
>
>1) Such a wrapper compiler would only be necessary for boost developers --
>i.e., those who wish to compile out of the CVS [development] tree.  As
>such, I'm not sure that it would apply to commercial users.

Then let me restate the problem - how would this developer use such a
wrapper in his IDE which comes with an integrated compiler (ie the compiler
is not called as an external program).  Yes I can enter multiple include
paths, but IMO this is an extreme evil - more than one during development
is possible but unpleasant; things start to get very flaky very quickly
(this developer much as well as the IDE!), so having one for each library
(if I'm to work on the checked out source), is probably a non-starter at
least for me.

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

Yes, but most compilers come with a version of make, I don't know any that
come with python - not yet anyway.

>I'm not saying that it won't discourage some commercial organizations from
>using boost if they have to install python to use boost.  I think it will.
>However, there are some commercial organizations that won't use boost if
>they have to COMPILE it. In addition, some organizations have policies
>against using libraries if they can't PAY someone for support.

True enough, but we should keep the bar as low as possible, unless there is
some major advantage to some tool.  BTW I have rejected free software in
the past because it used some esoteric make/configure system that was
unsupported on Win32.

>A single copy is nice, but you're not going to find too many sysadmins who
>are going to be willing to unzip the boost distribution inside /usr/local.
>They would be much more comfortable expanding and building boost in a
>separate tree and doing a separate "make install" process that they were
>confident only installs into common places (e.g., $prefix/lib,
>$prefix/include).

Let me clarify:  I'm not saying that we should not have an integrated
build/install system.  I am saying that it should not be mandatory to use
it, I would consider STLPort a reasonable example here - single developers
can work with the source tree "as is" - alternatively the whole thing can
be built and installed reasonably painlessly (OK I admit that the gcc
makefiles have no install step, mainly to keep them portable I would
guess).

>Boost should *not* limit itself to the idea of single-user installations.

No, I don't believe that we do, we just need an install script for the
current structure.

In my ideal world: we would write an "build/install generator", that is a
short script (any language you like, only the maintainer need run it) that
generates platform specific makefiles/install scripts based on it's
knowledge of the boost directory structure.  IMO we can do that perfectly
well with either the current structure, or something very like it.

BTW if you want to be able to install only parts of boost then all that's
needed to split the current monolithic include structure during the
install, is a list of which headers are required by each library (with
dependencies from there on worked out automatically).

Dreaming of utopia-ly yours,

- John