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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-09-30 10:05:36

From: "Rene Rivera" <grafik666_at_[hidden]>
> [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?

I'm not familiar with "abstract targets". I'll have to go read up on them
in a bit. But yes, I believe you've interpreted what I said correctly.

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

Well, I did change the syntax, to some extent. And I have no problems with
retaining backwards compatibility (though the current stage needs fixing).
I was proposing concepts, not a solution. I'll leave the actual solution to
you Boost.Build folks ;).

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

I think I follow that, though seeing some (hypothetical) code that uses this
would make it much clearer to me. But if I do understand this, it looks
fine to me.

> >* 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 :-)

I copied the current docs verbatim where it still applied ;).

> >* 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:

Sorry, I meant a variable specified in the target call, not a global
variable... so we're basically thinking along the same lines here ;).

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

Yep... exactly the idea I was thinking of.

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

Yep.

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

Well, of course, and I'm willing to help out in any way I can as you try and
come up with a solution. But right now how this issue is solved is
irrelevant to the higher level concepts we're discussing here ;).

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

Hmm... are you saying, when you mention additional compilation/link of
targets, that a variant could actually get built twice, once with the normal
name and once with the "tagged" name? That doesn't sound good to me. But
if I'm misreading that, I have no problems what so ever with keeping the
exact same syntax and getting it to "do the right thing" when it comes to
building... though I wonder if users might not find this confusing?

Bill Kempf