Re: [boost] Re: Directory Structure

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2000-12-18 09:28:41

On Sun, 17 Dec 2000, John Maddock wrote:

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

Excellent point -- I hadn't thought of that (unix bias blinded me here).

But as you mentioned below, don't most Windows compilers come with a make
type of system?  Can you just override the CCC or CXX (or whatever) make
macro to use the wrapper compiler?

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

Sure -- I'd agree with that.  If you install, you use boost in a certain
way.  If you don't install (i.e., use it from the development/CVS tree),
you use boost in a different way (perhaps with a wrapper compiler).

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

Gotcha.

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

That would be wonderful.

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

Also agreed.  It would be *Good* to re-split the .hpp files back into
their respective subdirectories, but if this makes an easy build mechanism
for boost developers not possible (although I believe that it must be,
somehow), the scheme you just outlined may be workable.

{+} Jeff Squyres
{+} squyres_at_[hidden]
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"