Re: [Scons-dev] Versioned libraries: non-standard sonames
Yep, i am doing such a suggestion. Well documented should not be a big
issue.
But the variable i am refering to, SOVERSION is one that i introduced in
a previous mail. I was proposing to rename it as ABIVERSION because the
SOVERSION refers to ELF platform, while ABIVERSION refers to the more
wide concept of ABI compatibility.
So, repeating again, we should add this flag:
-Wl,-soname=$SONAME
And then defining SONAME by default as something like:
env[SONAME]=$SHLIBPREFIX$TARGET$SHLIBSUFFIX.$ABIVERSION
env[ABIVERSION]=${'.'.join(SHLIBVERSION.split('.')[:ABIVERSIONLEVELS])}
env[ABIVERSIONLEVELS]=1
I am still scratching at the mac osx documentation to understand how ABI
compatibility works in that platform because for what i read, neither
the actual SCons code nor the one i had in my project handle that right.
El 01/01/14 23:17, Gary Oberbrunner ha escrit:
Hi David; the variable in question is SHLIBVERSION I think. Are you
suggesting changing the logic in Tool/__init__.py where it splits that
into
major, age, revision and uses major in the soname (-Wl,-soname=%s) so that
a different version number can be used in the soname, different from the
major version in SHLIBVERSION? That seems like a reasonable type of
flexibility, though it could be confusing if misused of course (as you
point out).
On Wed, Jan 1, 2014 at 11:32 AM, David García Garzón
david.gar...@upf.eduwrote:
El 01/01/14 00:30, William Deegan ha escrit:
David,
On Dec 31, 2013, at 10:12 AM, David García Garzón
david.gar...@upf.edu wrote:
I've been trying out the versioned libraries feature. As I said i do
like the nice interface you guys finally got. But i would like to
comment two issues i found. I open this thread about the first one:
Non-standard Sonames
Current implementation forces you to set the major version number
as the
soname suffix for your library. This is convenient in many cases, but
this doesn't cover the undesiderable but real cases in which the
soname
must be changed more than once between major versions.
Indeed in our project we left the first version for API changes,
and the
second version for ABI changes and the last one for ABI safe
changes. So
our soname has two version numbers and i think we are not a rare
case.
Indeed some projects have unrelated sonames and library names,
that is
far from ideal but real. So in general, i see convenient to be
able to
explicitly set the soversion for the library.
The solution i am thinkin on, in pseudo-python, would be:
soname = (
$SONAME if $SONAME else
libname+$SOVERSION if $SOVERSION else
libname+majorversion($SHLIBVERSION) if $SHLIBVERSION
)
So, how do you feel about this feature? I feel bold to implement it
myself, so give me a bless and i'll go for it.
So what would a linker command line look like for your use model?
-Bill
Structurally the command line does not change. At some point we add the
-Wl,-soname=%s flag in gcc tool chain specifying the soname and then
we create the symlink with the same name specified at the flag. I am
just arguing about how to compute such soname.
My suggestion would be adding the following flag instead:
-Wl,-soname=$SONAME
And then defining SONAME by default as something like:
env[SONAME]=$SHLIBPREFIX$TARGET$SHLIBSUFFIX.$ABIVERSION
env[ABIVERSION]=${'.'.join(SHLIBVERSION.split('.')[:ABIVERSIONLEVELS])}
env[ABIVERSIONLEVELS]=1
I just renamed previous SOVERSION as ABIVERSION because SONAME is
posix/linux centric and ABI compatibility version is a crossplatform
concept. I am opening a different discussion thread on this because i
think we are using it badly in Darwin and not using it at all in windows
platforms (cygwin, msvc and mingw).
David.
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] please try latest default branch
I tried upgrading our company build engine including the latest default branch and for std build it seems to work properly: the memory consumption is reduced compared to the standard version. Unfortunately we are getting many troubles with the interactive mode we use quite heavily. On the first build the interactive execution works fine but triggering a new build, the process is stopped due to missing input libraries during the linking stage. I need to dig more to better document the failure but is somebody else using the latest branch with interactive mode? Regards, Roberto From: scons-dev-boun...@scons.org [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary Oberbrunner Sent: domenica 29 dicembre 2013 13:30 To: SCons Dev List Subject: [Scons-dev] please try latest default branch This version has a significant memory optimization patch due to Dirk. Please try it on your real projects and let me know if it has any problems. (And ideally if you can measure memory use, if it helps with that too). -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] please try latest default branch
On Wed, Jan 8, 2014 at 12:35 PM, roberto de vecchi roberto.devec...@vi-grade.com wrote: I tried upgrading our company build engine including the latest default branch and for std build it seems to work properly: the memory consumption is reduced compared to the standard version. Unfortunately we are getting many troubles with the interactive mode we use quite heavily. On the first build the interactive execution works fine but triggering a new build, the process is stopped due to missing input libraries during the linking stage. Thanks Roberto -- just to confirm, interactive mode was working OK for you in 2.3.0 but not on default? Perhaps you can bisect to see which change caused it. Current tests pass, but they could easily be missing some cases for interactive use. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] Versioned libraries: non-standard sonames
On Wed, Jan 8, 2014 at 9:52 AM, David García Garzón david.gar...@upf.eduwrote:
Yep, i am doing such a suggestion. Well documented should not be a big
issue.
But the variable i am refering to, SOVERSION is one that i introduced in
a previous mail. I was proposing to rename it as ABIVERSION because the
SOVERSION refers to ELF platform, while ABIVERSION refers to the more
wide concept of ABI compatibility.
So, repeating again, we should add this flag:
-Wl,-soname=$SONAME
And then defining SONAME by default as something like:
env[SONAME]=$SHLIBPREFIX$TARGET$SHLIBSUFFIX.$ABIVERSION
env[ABIVERSION]=${'.'.join(SHLIBVERSION.split('.')[:ABIVERSIONLEVELS])}
env[ABIVERSIONLEVELS]=1
This is generally good. We're already generating the -Wl,-soname arg in
VersionedSharedLibrary (except for OpenBSD), so this just gives an escape
hatch for users to set it to something else.
Actually I'm not sure ABIVERSION and ABIVERSIONLEVELS are really needed;
the default value for SONAME can just contain the ${...} expression
directly. If users want to override SONAME they can set that to whatever
they want, e.g. $SHLIBPREFIX$TARGET$SHLIBSUFFIX.99. What do you think
about that? It seems simpler to me.
I am still scratching at the mac osx documentation to understand how ABI
compatibility works in that platform because for what i read, neither
the actual SCons code nor the one i had in my project handle that right.
OK, that sounds like a different patch perhaps, but a welcome one.
--
Gary
___
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] please try latest default branch
Gary, I think that the problem Im seeing is generated by the modification in FS.py around line 3052: def built(self): Called just after this File node is successfully built. Just like for 'release_target_info' we try to release some more target node attributes in order to minimize the overall memory consumption. @see: release_target_info SCons.Node.Node.built(self) if not hasattr(self.attributes, 'keep_targetinfo'): # Ensure that the build infos get computed and cached... self.store_info() # ... then release some more variables. self._specific_sources = False self.labspath = None self._save_str() self.cwd = None ß- removing the reset of self.cwd things look much better and I can build correctly with interactive mode. Just for your info we are running exclusively with variantdir enabled and no source duplication. If you can confirm the small change makes sense, Ill let some of our developer test more in detail this configuration. Regards, roberto From: scons-dev-boun...@scons.org [mailto:scons-dev-boun...@scons.org] On Behalf Of Gary Oberbrunner Sent: mercoledì 8 gennaio 2014 19:52 To: SCons developer list Subject: Re: [Scons-dev] please try latest default branch On Wed, Jan 8, 2014 at 12:35 PM, roberto de vecchi roberto.devec...@vi-grade.com wrote: I tried upgrading our company build engine including the latest default branch and for std build it seems to work properly: the memory consumption is reduced compared to the standard version. Unfortunately we are getting many troubles with the interactive mode we use quite heavily. On the first build the interactive execution works fine but triggering a new build, the process is stopped due to missing input libraries during the linking stage. Thanks Roberto -- just to confirm, interactive mode was working OK for you in 2.3.0 but not on default? Perhaps you can bisect to see which change caused it. Current tests pass, but they could easily be missing some cases for interactive use. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] please try latest default branch
On Wed, Jan 8, 2014 at 4:49 PM, roberto de vecchi roberto.devec...@vi-grade.com wrote: Gary, I think that the problem I’m seeing is generated by the modification in FS.py around line 3052: ... removing the reset of self.cwd things look much better and I can build correctly with interactive mode. Just for your info we are running exclusively with variantdir enabled and no source duplication. If you can confirm the small change makes sense, I’ll let some of our developer test more in detail this configuration. It makes sense to me, but Dirk will have to have a say. -- Gary ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] please try latest default branch
Hi Roberto, On 08.01.2014 22:52, Gary Oberbrunner wrote: On Wed, Jan 8, 2014 at 4:49 PM, roberto de vecchi roberto.devec...@vi-grade.com mailto:roberto.devec...@vi-grade.com wrote: Gary, I think that the problem I'm seeing is generated by the modification in FS.py around line 3052: ... removing the reset of self.cwd things look much better and I can build correctly with interactive mode. Just for your info we are running exclusively with variantdir enabled and no source duplication. If you can confirm the small change makes sense, I'll let some of our developer test more in detail this configuration. It makes sense to me, but Dirk will have to have a say. thanks a lot for testing the new version. Please continue with the reset of self.cwd commented out (or remove the whole line). If you find further issues, just let us know immediately. @Gary: Let's wait another day and see if Roberto finds more errors, then I'd prepare a pull request for removing the offending lines, okay? Trying to reproduce the failing build on our side and then working around it, is probably not a good idea so short before the release. Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
Re: [Scons-dev] please try latest default branch
Ok! Ill keep you posted! Cheers Roberto From: scons-dev-boun...@scons.org [mailto:scons-dev-boun...@scons.org] On Behalf Of Dirk Bächle Sent: giovedì 9 gennaio 2014 00:31 To: scons-dev@scons.org Subject: Re: [Scons-dev] please try latest default branch Hi Roberto, On 08.01.2014 22:52, Gary Oberbrunner wrote: On Wed, Jan 8, 2014 at 4:49 PM, roberto de vecchi roberto.devec...@vi-grade.com wrote: Gary, I think that the problem Im seeing is generated by the modification in FS.py around line 3052: ... removing the reset of self.cwd things look much better and I can build correctly with interactive mode. Just for your info we are running exclusively with variantdir enabled and no source duplication. If you can confirm the small change makes sense, Ill let some of our developer test more in detail this configuration. It makes sense to me, but Dirk will have to have a say. thanks a lot for testing the new version. Please continue with the reset of self.cwd commented out (or remove the whole line). If you find further issues, just let us know immediately. @Gary: Let's wait another day and see if Roberto finds more errors, then I'd prepare a pull request for removing the offending lines, okay? Trying to reproduce the failing build on our side and then working around it, is probably not a good idea so short before the release. Best regards, Dirk ___ Scons-dev mailing list Scons-dev@scons.org http://two.pairlist.net/mailman/listinfo/scons-dev
