[Scons-users] InstallVersionedLibrary sometimes fails when symlinking

[Andrew C. Morrow]

On Mon, May 27, 2013 at 11:03 PM, William Deegan
<bill at baddogconsulting.com>wrote:


> Andrew,

>

> Were you able to repro this? If so, should I file a ticket?

>

>

> Unfortunately, very busy IRL at the moment so haven't had a chance to try

> it out.

> Lots of work leading up to a conference, once that's over (6/6) I'll have

> some time to take a look at this.

>


Sounds good. I just wanted to make sure it didn't get missed. Built in
support for versioned shared libraries is a really useful feature and I'd
very much like to use it. I'm sure I'm not the only one.



>

>

> Also, is there some documentation on the SCons bugfix and release cycle?

> I've noticed that there are only infrequently 'z +1' releases of SCons

> x.y.z. If the problem with InstallVersionedLibrary is legitimate, should I

> expect to see a fix in a to-be-released-somewhat-soonish SCons 2.3.1 bugfix

> release, or longer term in some future SCons 2.4 release?

>

>

>

> SCons is a volunteer run open source project.

> If you want to ensure that a fix is made, you'll either have to submit a

> fix, hope that someone in the community picks up the issue and fixes it, or

> finance a consultant to resolve the issue for you.

>


I'm aware of the nature of the project. Still, this is a feature documented
in the SCons manual pages. Someone loved this feature enough to shepherd it
through development, code review, testing, documentation, and release.



> In general we will release a new version either when something notable has

> been fixed or if there's been a sufficient number of small fixes.

> If a fix is submitted for your issue (assuming it's not user error (which

> from a cursory glance it doesn't look like it is)), then it would be in the

> next release.

>


Right, but "next release" at which revision level, and on (roughly) what
time scale? Without some insight into the release process, intended
schedule, defect triage process, backport policy, etc., it is difficult to
reason about whether I should abandon my attempts to use this new feature
or not. Even if I were to debug this particular issue and submit a patch as
you have suggested, the adoption of that fix into a published release may
not mesh with my own release schedule. I'm not complaining - I merely want
to better understand: If I or someone else submitted a patch tonight, would
it likely land in a 2.3.1 release in one month, or in a 2.4.0 in 6 months,
or something else entirely?



> Also keep in mind all the work is done in a public mercurial repo hosted

> on bitbucket, so as soon as anyone published a fix you can try it against

> your build, and use that code if it resolves your issue.

>


That works well for projects that I plan to build for myself. However, for
open source projects which use SCons as the publicly facing build system it
is not a realistic solution to require downstream consumers to use the
SCons mainline or manually patch their SCons installs. Such projects are
constrained to use the demonstrably working subset of the official SCons
releases that make their way into distribution and language package
repositories. Potentially, a project could drag in the entire slug of fixed
code and redefine the InstallVersionedLibrary, but this has different
problems.

Thanks,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20130528/5b8a2a72/attachment.html