On 10/30/2010 09:25 PM, Philipp Thomas wrote:
On Fri, 29 Oct 2010 19:43:25 +0200, Dave Plater
wrote: I've already given them a patch to enable the libdir to be passed to scons and allow static library builds to use shared system libs which they've incorporated in svn.
I think you should be talking to upstream scons developers and ask them if there is a way to incorporate library versions. scons already has rules to determine what tool(s) and options to use for creating shared libraries and what prefix and suffix to use based on the host OS. It should be relatively easy to add library versions. But that needs people with knowledge of Scons and Python.
In the end you should be able to state major, minor and patch version and have scons turn that into
soname:
. lib_filename: . . . a symlink from
to the above plus a symlink soname to lib_filename, though the latter will automatically created by ldconfig when it's run it (un)installl time.
Does this mean that it isn't necessary to include the .so.0 link in the rpm? I've seen quite a few packages with it included.
Philipp
Ffado builds with scons and has library versioning, the developers have come quite far since early this year with scons builds. Their SConstruct and SConscripts layouts are quite different from openCOLLADA so unfortunately I couldn't use their ideas. I can't go messing up the collada windows and mac builds when I have their trust. They have a no release svn only policy so I can do what I like with the linux build part. The ffado scons build is an interesting one to look at it's in my home and multimedia:libs. One good thing has come from fighting with scons files is my python knowledge has gone from zero to novice without any studying. At least I;'m free to define a %libversion macro to version my libs in the spec file I would like to be sure that I'm doing it right though, I still don't quite understand the libtool versioning, current is obviously the major version number incremented when the api changes, the age.revision part is the confusing part but your use of major.minor.patch is clearer. Would the patch number indicate a change between releases?. Does cmake have a library versioning system? The openCOLLADA package contains a ruby script to generate CMakelists.txt'es and it seemed to work in my early days of trying to build openCOLLADA but I need to send it to factory before I try anything new, it doesn't seem like anything is going to change much in the future. Changing blender from scons to cmake took a while. I will attack the scons built in library versioning and soname matter when I've sorted out blender. The blender foundation has so many developers that it's difficult to get the right answers sometimes. I have a "no menus" problem which in the past was due to missing python scripts in the users home, I utilized a wrapper script but now the /.blender directory isn't built anymore, they've changed to %_datadir/%name/%version, and even with the scripts in every logical place I still have no menu. The main difference between my build and other blender people who have shared their cmake cache with me is, I don't use the embedded python3 I use the systems python3, if that's the problem then I'll have a valid bug, so I'm trying the embedded python3 at the moment. I had to install the windows version in vbox xp to see what it's supposed to look like. Unfortunately blenders ui generation is quite different to the norm which makes it difficult for me to use gdb. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org