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
> >at least start getting something concrete out of what we've talked about.
> >Here's my thoughts...
> >installation mechanisms for the various platforms. So, the first thing
> >do is to modify the stage target to create this structure for us. Here's
> >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
> >stage and in a further subdirectory from category. (For instance,
> >builddir/stage/bin and builddir/stage/doc). Alternately we can also
> >a new Jam variable, something like STAGE_PREFIX, that could entirely
> >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
> 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
> 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
> 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
> >the target (see below) will be used to insure copying of the correct
> >* 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.
> >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
> >current library won't be staged.
> You love variables ;-) The more consistent way and easier to understand
> to do that is to support using other stage targets as dependencies in
> 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
> >Boost to be quickly and easily staged, insuring that only those libraries
> >that truly work for the given platform are included. This idea should
> >it trivial to insure that anything installed on a platform will work on
> >platform, and would even make it rather simple to install only a portion
> >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
> >necessary for installing both Boost.Threads and Boost.Function, and only
> >both libraries actually build and pass regression tests for your
> 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
> ><tag> is meant to be used to create library files with specific names for
> >import library to still work. So either you have to fix this in the
> >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
> >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
> >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
> 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
> 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?
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk