On Thu, Jun 14, 2012 at 7:09 AM, Eric S. Raymond <[email protected]> wrote:
> Some months ago I observed a problem and reported that I have a > solution. The problem is the lack of a canned SCCons builder for > versioned shared libraries. I have field-tested code to fix this > in my SCons recipe for GPSD, which I'd like to push upstream. > > Last time I found the non-response from the project maintainers > disappointing. Of all the reasons I'm given for not moving to SCons, > this missing feature is #1 or #2 in frequency, up there with slow > builds. *Somebody* ought to be paying attention. > > Are any maintainers listening? > Hi -- yes we are! You're not the only one who's wanted versioned shared libs, so this would be a welcome addition. Let me look back at your message (8/8/11, "soname support" I believe). I apologize for the lack of response last year; SCons wasn't getting a lot of love right around then for various reasons. Looking back at it, I have a few comments. 1. it'll need documentation. We can help with that, though if you could rough it out that would be helpful. 2. it'll need tests. Is that something you could work on? 3. There are some places where you substitute vars earlier than they normally would be substituted, which might cause subtle bugs -- e.g. $SHLINKFLAGS gets substituted right when the user calls VersionedSharedLibrary, rather than at build time. There are SConsish ways around this. 4. (minor) I'd prefer names like shlib_pre_action_target to shlib_pre_action_output (at least if I understand the code correctly) Maybe the best way forward is to start a branch for it? (By the way, I was pretty sure we had a ticket for this in our Tigris bug tracker, but can't find anything related right now.) -- Gary
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
