Re: [jamboost] Stage targets for V2

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-05 12:59:46

Rene Rivera wrote:

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

I see the point. But this symbolic names are different
from the ordinary main target names -- main targets with different
names in different projects are not related. Rather, it's like fake
targets. Or you was saying that from the beginning but I did not understood?

(Side note: we don't yet have any fake targets)

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

Does it mean linking with different "-soname" option to the linker?

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

And the SO file as well? Or only 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 ;-\

I'll think about how we can do it.

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

Then, we can make staging use symlinks when explicitly specified.

>>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 should allow either directory or category for stages, not both.

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

Okay.

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

Okay, this is a good idea. What specifically do you plan to implement.
Does building tools/build/examples-v2/hello work for you, to begin with?

- Volodya