Re: [jamboost] Stage targets for V2

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

[2002-11-05] Vladimir Prus wrote:

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

Yes, I meant more like fake target. In V1 the stage is a fake target, it
just happens that the location is the same as the fake target name.

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

OK. Then we'll have to wait to implement the above. And therefore have some
time to discuss ;-)

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

That and the binary produced is also named different. For example this is
what I think Boost.Thread produces:

libboost_thread.12.9.0.so (real binary)
libboost_thread.so (symlink to real binary)

>> 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 file as well". The above example would produce, in a stage, and if
tagged with _debug:

libboost_thread_debug.12.9.0.so (real binary)
libboost_thread_debug.so (now symlink to libboost_thread_debug.12.9.0.so,
not libboost_thread.12.9.0.so)

>> 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.
Yes, that would be a good way to get both uses. In fact it might be usefull
to specify that for each source in the stage. Basically allowing to create
symlinks in the stage to arbitrary other targets.
>>>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.
Yes, good point. Any idea on syntax to differentiate them?
>> 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?
Yes, the hello example should work. I'll have to add DLL target stuff
though.
My intent would be to implement the soname part of DLL targets. If we don't
have DLL targets yet... I'll have to do that first :-)
The items to do the sonames would be:
1. A <dllversion> feature -- Possibly with a better name? Perhaps <version>
as one can version executables also.
2. Changes to linking to add the soname flags, and to generate the symlink.
Or perhaps a different link action just for this.
3. And, implement DLL targets if needed.
-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq - Grafik666_at_AIM - Grafik_at_[hidden]