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 <[email protected]> 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 <[email protected]> > wrote: >> >> On Fri, May 15, 2015 at 5:58 PM, Bill Deegan <[email protected]> >> 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 >> [email protected] >> https://pairlist2.pair.net/mailman/listinfo/scons-dev > > > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > -- anatoly t. _______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
