[Scons-dev] Shared library support for < 2.3.4 as a Tool (Was: Tutorial for Linux versioned libraries)

[anatoly techtonik]

I just interested to know if that's feasible. On the first look there is nothing
that prevents the external tool to detect and provide a replacement. But
simply copying the code from SCons codebase may not be enough,
because it may depend on other mechanisms not available in former
versions.

On Sun, May 24, 2015 at 5:17 PM, Bill Deegan <bill at baddogconsulting.com> wrote:
> Anatoly,
>
> Knock yourself out if you'd like to make the effort.
>
> I don't have any bandwidth or interest in backporting functionality to old
> versions.
>
> -Bill
>
>
> On Sun, May 24, 2015 at 8:01 AM, anatoly techtonik <techtonik at gmail.com>
> wrote:
>>
>> On Fri, May 15, 2015 at 5:58 PM, Bill Deegan <bill at baddogconsulting.com>
>> wrote:
>> >
>> > I'm fairly certain this issue is handled (at least in default branch and
>> > 2.3.4).
>> >
>> > The main SConstruct set's the soname and doesn't use the SCons logic to
>> > do
>> > the shared library versioning:
>> > src/SConstruct  (line 165)
>> >>    if sys.platform.startswith("linux"):
>> >>
>> >>
>> >> env.Append(SHLINKFLAGS="-Wl,-soname,${TARGET.file}.${libversion.split('.')[0]}")
>> ...
>> >
>> > I've sent a pull request with the changes:
>> > https://github.com/techtonik/RHVoice/pull/1
>>
>> That will mean that people will need scons 2.3.4, which is not
>> available even on Ubuntu LTS.
>>
>> Can this feature be provided as a tool to be dropped into scons-site/
>> directory? So that it will activate itself for previous SCons
>> versions?
>> --
>> anatoly t.
>> _______________________________________________
>> Scons-dev mailing list
>> Scons-dev at scons.org
>> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>



-- 
anatoly t.