Re: [Boost-install] Some Recent Thoughts on Boost Installation

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-09-28 12:22:11

[2002-09-24] William E. Kempf wrote:

>I've been thinking about the installation issues recently, and about how to
>at least start getting something concrete out of what we've talked about.
>Here's my thoughts...
[snip]
>installation mechanisms for the various platforms. So, the first thing to
>do is to modify the stage target to create this structure for us. Here's
my
>suggested syntax:
>
>stage <category> : <sources> : <requirements> : <default-BUILD> ;
>
>* Category (probably needs a better name) specifies what category of file
>(doc,bin,include) is being staged. The files will be moved to the build
>directory (which can be set with ALL_LOCATE_TARGET) in a subdirectory named
>stage and in a further subdirectory from category. (For instance,
>builddir/stage/bin and builddir/stage/doc). Alternately we can also
provide
>a new Jam variable, something like STAGE_PREFIX, that could entirely change
>the root directory (from builddir/stage) for staging, which would allow
>Boost.Build to actually be used as a crude form of installation script.

I'm trying to understand your suggestion... Are you saying that you want the
stage targets to act more like the abstract targets do now. That is
specifying many different "stage bin..." will collect all those into one
directory regardless of where they come from?

If that's the case I'd rather change the syntax of stage target not just
it's semantics. I'd like to keep backwards compatability, for the sake of
projects that use this (like mine). I suggest this instead:

stage <subdir-path> <type/category> + : <sources> : <requirements>
<default-BUILD> ;

Then a special stage: "stage some/dir * : ...", would be used to collect all
the various other stages available.

>* Sources is the same as main targets and one can list both generated
>targets like <exe>test_exe and individual files, but not template targets.

That's already supported :-)

>* Requirements specifies the build properties used as with main targets.
>The <tag> requirement won't be used (see below), but <tag> requirements of
>the target (see below) will be used to insure copying of the correct file.
>
>* default-BUILD acts in the same manner as a main target.
>
>One of the nice things about this idea is that header only libraries can
>provide Jamfiles that do nothing but stage their files for installation,
>providing a centralized and common location to specify this information. 
We
>can extend this idea further by adding another variable to the stage rule
>that specifies other libraries that we're dependent on. This would cause
>the other libraries to be built and staged first, and if they fail then the
>current library won't be staged. 

You love variables ;-) The more consistent way and easier to understand way
to do that is to support using other stage targets as dependencies in stage
targets. This was something that I intended on doing eventually. That is,
one could have this:

...in boost/libs/function/build/Jamfile:

stage stage bin : some-files... : ... : debug release ;

...and in boost/libs/threads/build/Jamfile:

stage stage bin : <dll>boost_thread <stage>../../function/build/stage : ...
: debug release ;

> Extend this further and you can require
>that a library pass it's regression tests before being staged (which is
>something that you may want to make overridable). This would allow all of
>Boost to be quickly and easily staged, insuring that only those libraries
>that truly work for the given platform are included. This idea should make
>it trivial to insure that anything installed on a platform will work on
that
>platform, and would even make it rather simple to install only a portion of
>Boost with out having to manually evaluate dependencies. For instance,
>Boost.Threads is dependent on Boost.Function, so the stage target would
>indicate this and by staging only Boost.Threads you'd get all of the files
>necessary for installing both Boost.Threads and Boost.Function, and only if
>both libraries actually build and pass regression tests for your platform.

The dependence on tests should also be done similarly, by having
dependencies on the test targets.

>In the above description I glossed over <tag>. There's a reason for that.
><tag> is meant to be used to create library files with specific names for
[snip]
>import library to still work. So either you have to fix this in the stage
>target, making it regenerate import libraries, which is something that's
>going to be compiler specific on how it's done, or you move <tag> from the
>stage target to the target that builds the libraries. This has been
>discussed on the bjam mailing list, so I won't rehash the discussion, and I
>don't really care how the problem is resolved. The reason to bring it up

But I do care ;-) And I've been thinking about it since you posted... I have
an idea for a solution that would only require small changes to the build
system, and no changes to the toolset files. The gist of it that the stage
target would temporarily impose the additional <tag> requirements on the
targets it depends on. And they in turn generate directly the binaries with
the correct name. This has the benefit that it doesn't impose additional
syntax changes, and basically would fix the name problems. The drawback is
the additional compilation/link of the targets, but I'll try to reduce this
as much as possible. 

**** Dave, as this impacts Boost.Python and it seems like something that
woulb be good to get fixed ASAP (for the release)... I'll work on getting my
solution working.

>Bill Kempf
>
>P.S. I CCed the jamboost list, as this discussion directly involves the
>readers there as well.

And inversely I'm CCing the Boost-Build list.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]