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

Eric S. Raymond esr at snark.thyrsus.com
Sun Mar 22 20:35:20 EDT 2015


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>


More information about the Scons-dev mailing list