On 10/30/2010 09:25 PM, Philipp Thomas wrote:
On Fri, 29 Oct 2010 19:43:25 +0200, Dave Plater
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
a symlink from <lib_prefix><lib_name><lib_suffix> 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.
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
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.
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org