Re: [jamboost] Stage targets for V2

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-05 07:41:32

Rene Rivera wrote:
>>1. Do you want stage directory to be relative to build directory
>>for the current project? IOW:
>>
>> stage bin-stage ....
>>
>>can place targets to

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

OK.

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

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

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

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

Maybe....

>>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 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'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? Then,
we might first implement simple stage

stage path : sources : requirements : default-build ;

And then think about type.

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

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

- Volodya