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
> 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.
>>>It depends on what "relinking" does. In V1 with GCC linking does two
>>>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
>>>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
>>>both names). Now if we change the name with <tag> we also need to change
>>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
>>>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
>>>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
>>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
> 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
and look at the test directory that is preversed. Or look at
the test itself -- it's short.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk