[Scons-dev] Support for versioned shared libraries is nowhere near fixed

[Bill Deegan]

William,

Eric did contribute the initial implementation, if I remember correctly.

SHLIBVERSION can be used as:

env.InstallAs(target = '/usr/local/bin/foo',
              source = 'foo_debug',

              SHLIBVERSION='10.5.2')

I do agree that the language in the manpage is not very good.

The reason for having it as an Environment variable is that is the
"scons way",  Builder's have source and target, all other arguments
are used to create an OverrideEnvironment().

So effectively each node in the DAG has sources, targets, and an
environment to us to build them.

-Bill


On Sun, Mar 22, 2015 at 9:15 PM, William Blevins <wblevins001 at gmail.com>
wrote:

> Eric,
>
> I am sorry this has caused you problems; however, your attitude is
> irrational.
>
> Firstly, this is a purely open source project: SCons has NO paid
> developers.  Though the SCons team tries very diligently to deliver the
> best build tool possible, we CANNOT do everything.
>
> Secondly, YOU may contribute.  YOU may fix any issues that you encounter;
> therefore, you COULD have patched this legitimately whenever you saw fit if
> it truly caused you problems.
>
> I agree that the version shared lib implementation isn't as good as I
> would like, but it does the job.  I rarely have any two items that build
> with the same environment object, but you can do environment clones.
>
> V/R,
> William
>
> On Sun, Mar 22, 2015 at 8:35 PM, Eric S. Raymond <esr at snark.thyrsus.com>
> wrote:
>
>> Viewing http://scons.tigris.org/issues/show_bug.cgi?id=2869 I see it
>> asserted that "It's used in production for the gpsd project already."
>>
>> This is true insofar as GPSD has my original code still in use.  In fact,
>> the adaptation into the SCons codebase was so badly mangled that I
>> have found it unusable, and to make matters worse the mangled feature
>> is effectively undocumented.
>>
>> The continuing failure of the scons developers to effectively address
>> the versioned-shared-library issue has led to *all* of the most
>> serious maintainance problems GPSD has over about the last three
>> years.  I am coming under pressure from my Debian packager to abandon
>> scons because of this issue - he has actually implied a threat to fork
>> the project over it.  I can hardly blame him - I too have become fed
>> up with maintaining a fragile set of kluges to address an issue that
>> scons should have long since *solved*.
>>
>> Let's review the only mention of versioned shared libraries on the
>> manual page
>>
>>
>> --------------------------------------------------------------------------------
>>        env.InstallAs()
>>               Installs  one  or  more  source files or directories to
>> specific
>>               names, allowing changing a file or directory name as part
>> of the
>>               installation.  It is an error if the target and source
>> arguments
>>               list different numbers of files or directories.
>>
>>        InstallVersionedLib()
>>
>>        env.InstallVersionedLib()
>>               Installs a versioned shared library. The $SHLIBVERSION
>> construc‐
>>               tion  variable  should  be defined in the environment to
>> confirm
>>               the version number in the library name.  The symlinks
>> appropri‐
>>               ate to the architecture will be generated.
>>
>>               env.InstallAs(target = '/usr/local/bin/foo',
>>                             source = 'foo_debug')
>>               env.InstallAs(target = ['../lib/libfoo.a',
>> '../lib/libbar.a'],
>>                             source = ['libFOO.a', 'libBAR.a'])
>>
>>
>> --------------------------------------------------------------------------------
>>
>> What's wrong with this?  Well, let's start with the fact the
>> (inadequate) documentation has been inserted between the documentation
>> for env.InstallAs() and its example.  If scons aims to be used for
>> serious development work, you cannot ship sloppy crap like this.
>>
>> Continuing: there is no example of an InstallVersionedLib() call. It
>> says: "$SHLIBVERSION construction variable should be defined in the
>> environment to *confirm* the version number in the library name" What
>> does *confirm* mean here? Is it duplicatively specified elsewhere?
>>
>> There was no $SHLIBVERSION in the recipe I sent you.  My
>> VersionedSharedLibrary() takes a version number argument for the
>> excellent reasion that I have to build *two shared libraries in the
>> same environment*.  The choice to 'clean up' my code by introducing
>> this $SHLIBVERSION thing made it unusable for its intended purpose.  I
>> am unable to think of any reason for it, and would love to hear some
>> explanation as to why I shouldn't consider it completely idiotic.
>>
>> I can't use this 'feature' as it is now, and I'd bet heavily that
>> nobody else has ever tried.
>>
>> Yes, I'm quite angry about this.  Between them, the failure of SCons
>> to solve this problem out of the gate and the utterly botched
>> adaptation of my fix have cost me large amounts of time and effort.
>> Now it may force me back to the huge, festering pile of crap that
>> is autotools.
>>
>> "Not worse than autotools."  That should not be a high bar to clear,
>> but you're *failing*.  What are you going to do about it?
>> --
>>                 <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150322/6f7c3b6e/attachment-0001.html>