Re: [jamboost] Stage targets for V2

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-11-04 16:22:20

[2002-11-04] Vladimir Prus wrote:

>
>Okay, I'm about to implement stage targets for V2,
>and I have certain questions.
>
>1. Do you want stage directory to be relative to build directory
>for the current project? IOW:
>
> stage bin-stage ....
>
>can place targets to
>
> current-project-dir/bin/bin-stage

No.

>or to
>
> current-project-dir/bin-stage

Yes.

>This matters if I want to write:
>
> stage my_project_root/bin
>
>I.e. to stage target to a certain directory.

Yes, it does. Additionaly it should be possible to support absolute
locations. I was thinking we should support a <location> feature so that we
can have the symbolic name and still put the stage anywhere we want.

>2. Can anybody explain me the situation with <tag>?
>
> - When change of target name requires relinking

Almost all the time. We just can't guarantee what the toolset requires when
linking well enough to be optimal about this aspect. Right now (v1) the
operation is to always re-link any new name of the target.

> - Does <tag> work now for main targets as well?

Yes, although the syntax in v1 is bit clunky :-( As one has to put in
additional grist<> elements to account for the <toolset><variant> parts. So
I'm certainly open for better ways to specify alternate naming of targets. I
know Dave suggested once upon a time to have a single <name?> feature that
would run a rule to rename the target.

>3. Is it a good idea to use symlinks on Unix when staging?

That depends on the context. If you mean doing symlinks instead of copying,
then no. If you mean the symlinks that things like sonames would need then
yes. But, as I found out, those need to get regenerated when the target name
changes.

>4. I've lost track of "stage" discussion on boost-install mailing list.
>If anybody remembers the conclusions, it could save me half an hour of
>browsing emails.

I don't remember either, but luckily I keep all those emails. Here's my most
pertinent response to the stage rule... with some additional comments...

[2002-09-28] Rene Rivera wrote:
>[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.

The basic idea here is to categorize stage targets into groups so that many
stage targets can be built from a single fake target. This would allow
easier creation of targets like "dist" and "install".

>>* 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. 
[trim]

As you know the above is now implemented. But there is one thing left to do
to make it ideal. As it is when the name of the target changes it relinks to
the variant subdirectory. But the ideal when used within the context of
stage targets is to relink to the stage location. This removes the extra
copy step and might be important for platform that encode the absolute
location of files in the binaries for debuggin use.

And hence my above suggestion of a <locate> feature. If we can have such a
feature for any target it would make it really easy to implement the relink
into the stage.

If you get a basic version of the stage target working I can certainly take
over after that and put in more details. Right now what's stopping me from
doing more work on V2 is trying to understand the HUGE amount of work you've
done ;-) -- About the only other build system related thing I'm doing now is
the simplified jam build scripts, basically done.

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