Hi David; the variable in question is SHLIBVERSION I think. Are you suggesting changing the logic in Tool/__init__.py where it splits that into major, age, revision and uses major in the soname (-Wl,-soname=%s) so that a different version number can be used in the soname, different from the major version in SHLIBVERSION? That seems like a reasonable type of flexibility, though it could be confusing if misused of course (as you point out).
On Wed, Jan 1, 2014 at 11:32 AM, David García Garzón <[email protected]>wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > El 01/01/14 00:30, William Deegan ha escrit: > > David, > > > > > > On Dec 31, 2013, at 10:12 AM, David García Garzón > <[email protected]> wrote: > > > >> I've been trying out the versioned libraries feature. As I said i do > >> like the nice interface you guys finally got. But i would like to > >> comment two issues i found. I open this thread about the first one: > >> Non-standard Sonames > >> > >> Current implementation forces you to set the major version number as the > >> soname suffix for your library. This is convenient in many cases, but > >> this doesn't cover the undesiderable but real cases in which the soname > >> must be changed more than once between major versions. > > > > > >> > >> Indeed in our project we left the first version for API changes, and the > >> second version for ABI changes and the last one for ABI safe changes. So > >> our soname has two version numbers and i think we are not a rare case. > >> Indeed some projects have unrelated sonames and library names, that is > >> far from ideal but real. So in general, i see convenient to be able to > >> explicitly set the soversion for the library. > >> > >> The solution i am thinkin on, in pseudo-python, would be: > >> > >> soname = ( > >> $SONAME if $SONAME else > >> libname+$SOVERSION if $SOVERSION else > >> libname+majorversion($SHLIBVERSION) if $SHLIBVERSION > >> ) > >> > >> So, how do you feel about this feature? I feel bold to implement it > >> myself, so give me a bless and i'll go for it. > > > > So what would a linker command line look like for your use model? > > -Bill > > Structurally the command line does not change. At some point we add the > "-Wl,-soname=%s" flag in gcc tool chain specifying the soname and then > we create the symlink with the same name specified at the flag. I am > just arguing about how to compute such soname. > > My suggestion would be adding the following flag instead: > > -Wl,-soname="$SONAME" > > And then defining SONAME by default as something like: > > env["SONAME"]="$SHLIBPREFIX$TARGET$SHLIBSUFFIX.$ABIVERSION" > > env["ABIVERSION"]="${'.'.join(SHLIBVERSION.split('.')[:ABIVERSIONLEVELS])}" > env["ABIVERSIONLEVELS"]=1 > > I just renamed previous SOVERSION as ABIVERSION because SONAME is > posix/linux centric and ABI compatibility version is a crossplatform > concept. I am opening a different discussion thread on this because i > think we are using it badly in Darwin and not using it at all in windows > platforms (cygwin, msvc and mingw). > > David. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSxEMjAAoJEGmqNTFmabRELl0P/2gOTRIr4Cmtj2ivynvlDH27 > JijbWRRoQT2K4VYtFwoId3pIaZrgTky76z5jTNq9bwkHTb/l7HtQkWpmdDqwdEZe > Vx5gx0It0OByQi8PkSqW7zOjgm59yezIFfCHS6J6HrsZIxXNUsujjaQ0xvhI7C/u > Tv9BFT+pTz/D34UBlbMM5vakmUWQyQP0Bx2yl/GOYoxtmjxUJRpSSO3lIAoUqpMW > L66BDycrZgHaesCsxvKR6tIy9yOUOcqPHtU+7AmqkUfeXV8FfomduOJSscaAf9y9 > OuRCDWV+6vb6E+hriFcxo+veUU79xBla7ZIsZ28U+sBdHxygMxRh1Hi6+M6XeQHy > YBwXj9mbk6M8qnZoiiIAZpfcegXC2IJO5vX748XOITq0tsGLi2gKft92dcMkH0If > Ad37SnpOiMwk1EhfHdtIYSiFB8yXjbDk6WBhtl/+Z05jGOtIifzWUYEjUm2F1N+A > iKkNJEXxtIqcxhtTHvNb/ocWV9/7HoKX5FfOp/VhvvmrrKgSAZzHPJ2LvOP6dcOz > aK8A4LSfi9cGevApkutFxVusZSyL4wC8aoOSwVZmpp16ScuVqXxjE2WmcLlx27Xa > tMdhsD66M/Gy+xTSxFNt0xu5dKC5mJQ+j8RrkTC/0EuacLiI+aQEpqSo0cdRVVHl > EqT6uaHpCASXn+5Z5xMh > =QlVK > -----END PGP SIGNATURE----- > > _______________________________________________ > Scons-dev mailing list > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev > -- Gary
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
