Re: [jamboost] Stage targets for V2

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-10 09:39:04

Rene Rivera wrote:

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

Understood.

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

And if we place different binaries in different directories but with
the same name, then the dynamic linking will have difficulties finding
the right one?

Okay.. I seem to understand this better now, thanks. One more question on topic:
is there a way to hardcode the path to shared library in exe? I want it in
order to avoid setting LD_LIBRARY_PATH when debugging, when libraries live
in build directories.

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

Nice idea. We'd need a mechanism for specifying different processing for
different sources, though.

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

Nothing especially bright, other then prepending something to
category.

>>>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 :-)

We have DLL target: "lib". Whether "lib" target generates static or shared
library is determined by the value of "shared" property.

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

I'm not 100% sure, but <version> seems better.

> 2. Changes to linking to add the soname flags, and to generate the symlink.
> Or perhaps a different link action just for this.

OK. There's minimal soname support there (just at the bottom of "gcc.jam"),
and you can start improving from there, I guess.

> 3. And, implement DLL targets if needed.

Not needed, I think. BTW, stage targets are implemented now. I've no
example in CVS, but you can easily get one. Run

PRESERVE=1 $boost_root/tools/build/test/stage.py

and look at the test directory that is preversed. Or look at
the test itself -- it's short.

- Volodya