[Scons-dev] Issue 2869 - Versioned shared libraries

[Managan, Rob]

Bill and Dirk,

I think I tend to agree with Bill that Install should not surprise the user. For ease of finding the functionality I will look at adding InstallVersionedLibrary so it naturally sorts along with Install and InstallAs. I suppose I can try to make it smart enough to figure out if the file it is copying has the version number in it or not.

The one downside I see with that is a user providing a different version number in the Install than he used in building the library.

That raises another question since I don't normally deal with these. Is there a real need to build the library with the version number in the local space for testing purposes? Or do people normally build the library w/o version number and then add version number and sym links only when they install it in the system location? In other words, is there a real need for SHLIBVERSION?? I suppose so since Eric Raymond went to the effort to write his function.

Thanks for the comments, Dirk. I had cleaned things up a little but like the idea of more encapsulation. I really wanted to get a trial balloon out there since it at least worked.

Am I correct that changing the target name so that the real file includes the version number and the original target name is now a sym link is OK?
For example, w/o SHLIBVERSION, you get libtest.so, with it you get libtest.so.2.5.4 and lib test.so is a sym link. I did it that way since the provided method did that.

Rob


On 10/25/12 12:13 PM, "William Deegan" <bill at baddogconsulting.com<mailto:bill at baddogconsulting.com>> wrote:

Rob,
On Oct 25, 2012, at 11:24 AM, Dirk Bächle <tshortik at gmx.de<mailto:tshortik at gmx.de>> wrote:

Hi Rob,

just had a quick look at your changes...thanks a lot for taking care of this issue.

On 25.10.2012 06:09, Managan, Rob wrote:

I want to get some input on this issue. I created a fork for this at https://bitbucket.org/managan/scons_soname and put Eric Raymond's code into Environment.py that added the methods VersionedSharedLibrary and VersionedSharedLibraryInstall.



...



We could just create the sym links for any library whose name includes a

3 digit version number like libtest.2.5.4.so or libtest.dylib.2.5.4. Is that rare enough that it is OK to just do it or what do people think about how to roll this behaviour into the main methods?


Another way to say this is: what should the user interface be??

Your suggestions are fine with me, this should be what most users want...and like this, they have it at their fingertips. +1 from me. ;)

For keeping everything ultra-flexible, you might want to take the following into consideration:
I'd like to see the code for detecting "this is the name of a versioned shared lib" and spitting out the basename and
major/minor numbers encapsulated in a small function. The default behaviour, as defined by you so far, is definitely good enough to go. Although the RPM docs try to remind people that the "x.y.z" numbering is not a convention, it can be seen as one in current practice, at least from my angle. But for those weird cases someone might come up with in half a year or so, it would be cool if I could override the "versioned lib detection" with my own code for a single Environment...(e.g. using a no-op function to suppress any further actions, like adding symbolic links, for a versioned lib).
This doesn't have to be user-friendly, it should somehow be possible.

Does it really make sense to have Install() recognize versioned shared libraries?
VersionSharedLibraryInstall() seems like a better way to handle this.
Less magic under the covers is better..

-Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20121025/d27882d1/attachment.htm>