Re: [jamboost] Stage targets for V2

From: Rene Rivera (grafik666_at_[hidden])
Date: 2002-11-05 12:25:17

[2002-11-05] Vladimir Prus wrote:

>Rene Rivera wrote:
>>>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.
>
>This idea did not occured to me. However, why do we need symbolic names?
>For building specific stage?

The one example I know of that a symbolic name would be good to have is when
trying to stage to a system global location. For example if you want to
install to "/usr/local/bin" or such, or "C:\WINNT", that is common abosolute
locations. Then it's preferable to use a symbolic name, like "binaries",
instead of trying to name the stage "/usr/local/bin". Of course this assumes
that we allow abosulute path stages.

>>>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.
>
>Hmm... I actually don't know *why* relinking is necessary at all with,
>for example, gcc.

It depends on what "relinking" does. In V1 with GCC linking does two things
with respect to DLLs: links the binary to an versioned name, creates a
symlink to the binary as the unversioned name. This is the "standard" for
Linux type SOs and is required to support correct linking (the linker uses
both names). Now if we change the name with <tag> we also need to change
symlink.

So if you don't include the symlink as part of the lining, then no relinking
is not needed in GCC.

But relinking is always needed in Windows! So if we can be very
discriminating then we can minimize the stage so that it only relinks in
pltforms that require it. That is the part that was not possible in V1
because it would require changing all the toolsets... which is what we are
doing in V2 ;-\

>>> - 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. 
>
>The current V2 syntax is
>
> gcc,debug:<tag>tra_la_la
>
>which is slightly shorter, but only slighter.

At least it's easier to type.

>>>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. 
>
>Why? My use case is that I want to place all the binaries of a project to
>a single location, so that they can be easily located. And the copying
takes
>noticable time.

If your goal is to use the stage as a shortcut to the binaries then yes it's
OK. But my use case (the project I'm working on) is to collect the binaries,
and other configuration files for further use. The further use is similar to
what was brought up in the Boost.Install discussions. If you want to archive
(tar,zip,etc) the stage for distribution, or for use by an installer program
(rpm,dpkg,etc). In that case symlinks are not wanted, the real files are.
Otherwise programs like tar will store the symlinks instead of the files ---
Yes I know one can configure tar to follow symlinks, but this is not a
universal feature of tars, or other programs.

>> 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.
>
>Uhm.. I don't understand what you say above. I'm not that fluent with
sonames/
>dynamic loading, etc.

I think I answered this above. If not I can explain it in more detail.

>>>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".
>
>Is the only purpose to "category" is to build several stages at once?

Unfortunately no :-( I'll point out the above suggestion marked by "^^^^",
or at least my understanding of the original suggestion. The idea is to make
a union of all the same category stages and stage them all to a single
location. This would make it easier, for eaxmple, for Boost developers to
add libraries that will get all collected into a single pre-install stage
without having to edit one global file.

> Then,
>we might first implement simple stage
>
> stage path : sources : requirements : default-build ;
>
>And then think about type.

That's fine by me. We can talk about how to do the additional category
collection stuff later.

>>>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.
>
>I think we can implement this.
>
>> 
>> 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.
>
>Understood. The only problem is that it kind of breaks the existing system,
>where target paths a determined by properties in an implicit way. What's
even
>more problematic is that if you make "<locate>" an ordinary free feature,
>then you can build the same main target with two values of "<locate>". The
>system will notice that non-free properties are the same and will return
>already built targets. Probably, the "stage" rule can do some magic itself.

Understood, I ceratinly don't want to make it harder on you right now ;-\ So
if doing it by magic is easier go for it!

>> 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 ;-) 
>
>:-)
>Well... if you do have time to work on it, I can find some
>relatively independent and small task for you, and help with any issues you
>encounter.

Well, I have an idea in this regard... since you are unfamiliar with the
soname stuff I could try and implement that funtionality and see what issues
come up.

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