Re: [MoM] kmer-tools status update
Hi, Andreas,
On الأربعاء 27 أيار 2015 05:29, Andreas Tille wrote:
I have tried the library packaging, but there is no soname and I am not sure
how to assign one since I don't know the state of the interface and how this
changes between different svn revisions.
I have committed my attempts to the "sharedlibs" branch (or some similar
name), leaving master in a working state. The sharedlibs branch does not
build because an actual file is found rather than a symlink to the
library+soname, as I describe in my commit message.
I checked this and while you correctly noticed that there is "some" option
to get a dynamic library this is not the libtool option which enforces a
clean library. The build in the sharedlibs branch fails since d-shlibmove
is requiring a symlink for the *.so file. Out of curiosity I checked on my
local machine
$ readlink /usr/lib/x86_64-linux-gnu/*.so | grep \.so$
libncurses.so
libldap_r.so
libpng12.so
so we do have counter examples to this (surely not build with d-shlibs)
and so it might be possibly to forget d-shlibs and move around the files
via usual dh_install but I think we should draw a cutting line here. I'd
(strongly) recommend to upstream using autoconf + libtool to get a proper
build system and we could live with the static lib for the moment.
Okay, but I wouldn't hold my breath for getting a new build system here.
Upstream seems to have gone out of there way to get a build system with
non-recursive Make. I'll have to bring this up with him and see what he
says. If he's willing to go with it, I would probably end up being the
one to implement it.
By the way, wgs-assembler uses the same build system. The upside,
though, is that it doesn't make any libraries--at least as far as I know.
In this view, this looks like it will take a little time and some
communication with upstream to sort out. Please upload the current state if
it all looks good to you.
When doing some experiments with the sharedlibs branch I tried a simple
debuild after the build failed due to the d-shlibmove check. I realised
that the build in this case failed at some earlier (totally unrelated)
point. I think this is a sign that the clean target does not leave the
directory tree in the same state as before the first build which has the
effect that the package does not build twice in a row. This is
considered an error and there are people running checks on the archive
from time to time and file according bug reports.
That is strange. I will have to keep an eye out for this behavior, but
I'd rebuild several times at one sitting throughout the packaging
process and haven't encountered any such issues. This might just be a
problem with the sharedlibs branch.
For the moment I do
not consider this a large enough problem to stop me from uploading to
new and so I did this. :-)
Thank you!
I just wanted to prepare you about things
that might be necessary to do once the package will reach the package
pool but perhaps meanwhile the build system has changed and the
situation at this point will be different anyway and the problem might
have vanished silently.
Good to know.
Thanks for your good work on this complex package for a MoM project
And thank you for your help and support throughout the process.
Regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
Reply to: