[Scons-users] InstallVersionedLibrary sometimes fails when symlinking

[Managan, Rob]

Hi Andrew,

Good catch. They probably are not cleaned as well. Let me see what is involved to fix that.

Rob

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Rob Managan                             email managan at llnl.gov
LLNL                                             phone: 925-423-0903
P.O. Box 808, L-095                   FAX:   925-422-3389
Livermore, CA  94551-0808


On 6/2/13 10:13 AM, "Andrew C. Morrow" <andrew.c.morrow at gmail.com<mailto:andrew.c.morrow at gmail.com>> wrote:


This is most likely related to the above, but it also appears that the installed symlinks are not captured by FindInstalledFiles, which means that Package (if I'm reading it correctly) won't package the symlinks.

Thanks,
Andrew



On Sat, Jun 1, 2013 at 2:09 PM, Andrew C. Morrow <andrew.c.morrow at gmail.com<mailto:andrew.c.morrow at gmail.com>> wrote:

Hi Rob -

Sorry it took me a couple days to get back to this. I just tried out your branch. The good news is that the issue with the build failing due to errors while symlinking is fixed, so that is a big help.

While experimenting with the fix though, I've noticed another issue. Using the same test case as before:

$ python $MYSCONS/script/scons.py --prefix=$(pwd)/install install
SCons import failed. Trying to run from source directory
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
Install file: "build/foo.hpp" as "install/include/foo.hpp"
g++ -o build/foo.os -c -fPIC build/foo.cpp
g++ -o build/libfoo.0.1.2.dylib -dynamiclib -current_version 0.1.2 -compatibility_version 0.1.2 -undefined dynamic_lookup build/foo.os
Install file: "build/libfoo.0.1.2.dylib" as "install/lib/libfoo.0.1.2.dylib"
scons: done building targets.

Everything builds OK. Lets remove the symlink in the install directory:

$ rm install/lib/libfoo.dylib

Rerunning the build claims install is up to date:

$ python $MYSCONS/script/scons.py --prefix=$(pwd)/install install
SCons import failed. Trying to run from source directory
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
scons: `install' is up to date.
scons: done building targets.

And the file was not re-created:

$  ls install/lib/libfoo.dylib
ls: install/lib/libfoo.dylib: No such file or directory

The same effect is observed removing libfoo.dylib from the build directory. So it appears that there are some dependency edges that are not being captured correctly.

Thanks,
Andrew



On Thu, May 30, 2013 at 2:08 PM, Managan, Rob <managan1 at llnl.gov<mailto:managan1 at llnl.gov>> wrote:
Andrew,

I have a proposed fix at https://bitbucket.org/managan/scons_versionedlib .
Let me know if it works for you.
I added code to delete any existing symlink before creating them again. That was how it failed for me even if the error message seemed to say something else. I also made sure the symlinks in the install directory were set up the same as in the build directory. Not sure how that ever was different.

I need to add a test case before generating a pull request but this should be good to go.

Rob

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Rob Managan                             email managan at llnl.gov<http://llnl.gov>
LLNL                                             phone: 925-423-0903<tel:925-423-0903>
P.O. Box 808, L-095                   FAX:   925-422-3389<tel:925-422-3389>
Livermore, CA  94551-0808


On 5/27/13 10:46 PM, "William Deegan" <bill at baddogconsulting.com<mailto:bill at baddogconsulting.com>> wrote:

Andrew,

On May 27, 2013, at 10:04 PM, Andrew C. Morrow <andrew.c.morrow at gmail.com<mailto:andrew.c.morrow at gmail.com>> wrote:


On Mon, May 27, 2013 at 11:03 PM, William Deegan <bill at baddogconsulting.com<mailto: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.

Though all of this is true, that doesn't guarantee that the developer of any feature is immediately available to address a bug.



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?

If this is a bug in an existing feature (and assuming the fix doesn't require breaking compatability), then the fix would show in the next minor release published after a fix is accepted.
This likely means 2.3.1, however if other less trivial (assuming the fix is fairly trivial) changes have already landed in the main branch, then it might appear in the 2.4.0 branch.
There is not direct correlation between a 2.3.1 release or a 2.4.0 release and a timeline.




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.

Fair enough.
Note however that SCons can be run in place with a scons-local package, so you could unpackage a build scons-local package from the latest code and check that into your project until such time as the needed fix is released.

Hope that helps.

In the meantime, it looks like Rob is hot on the trail of this issue.. so stay tuned.

-Bill

_______________________________________________
Scons-users mailing list
Scons-users at scons.org<mailto:Scons-users at scons.org>
http://four.pairlist.net/mailman/listinfo/scons-users



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20130603/368e895d/attachment.htm