Re: Homepage of LibMems?
On Mon, 25 Feb 2008, Aaron Darling wrote:
Andreas Tille wrote:
On Sat, 16 Feb 2008, Aaron Darling wrote:
libMUSCLE is based on the MUSCLE aligner v3.6, and contains several
bugfixes and features not available in the main muscle distribution.
Muscle was released public domain, so libMUSCLE inherits a public domain
license.
Well, the license in principle permits this strategy. On the other hand
one goal of the Debian-Med project is to prevent people from forking by
providing the best and most feature rich software to fit the needed
applications.
In this aspect we would have liked it more to contact the MUSCLE authors
by sending them a patch. I hope that the author of the muscle package
in Debian will be able to sort this out. We would be happy if this would
support your work in Mauve.
The Makefiles I have created for libMUSCLE also build the standalone muscle
binary. If the library were updated to include Bob Edgar's changes for
muscle 3.7, would libMUSCLE alone be sufficient for debian-med?
Well, we currently have a muscle package inside Debian. My suggestion
would be the following:
Provide your patch to build libmuscle (I'd prefer lower case library
names if possible) and convince upstream to provide the feature to
build the binary linkes against this library. This enhances flexibility
and ensures, that everybody uses a common code base. The danger that
the code diverges over time is to high.
In Debian we could start building the packages based on your makefiles
and send the patches to the Muscle authors - perhaps that might be more
convincing. At least it would helpt to build Mauve binaries based
on the latest code of Muscle without duplicating anything.
It seems I may have spoken too soon about a lack of a workaround for the
static library versioning and the duplicate version number issue. It turns
out that removing the "-release" option from the LDFLAGS portion of
Makefile.am also removes the duplicate version identifier from the resulting
library name.
I admit I can not verify this behaviour. I tried
$ diff -u orig/libGenome-1.3.0/libGenome/Makefile.am ad_patch/libGenome-1.3.0/libGenome/Makefile.am
--- orig/libGenome-1.3.0/libGenome/Makefile.am 2007-01-31 06:39:56.000000000 +0100
+++ ad_patch/libGenome-1.3.0/libGenome/Makefile.am 2008-02-25 13:14:09.000000000 +0100
@@ -37,7 +37,7 @@
lib_LTLIBRARIES = libGenome-1.3.la
libGenome_1_3_la_SOURCES = $(LIBGENOME_SRC)
-libGenome_1_3_la_LDFLAGS= -version-info $(GENERIC_LIBRARY_VERSION) -release $(GENERIC_RELEASE)
+libGenome_1_3_la_LDFLAGS= -version-info $(GENERIC_LIBRARY_VERSION)
which created also the double versioning. Could you send your version
that would worl otherwise?
The approach is still somewhat unsatisfying since I have to
update my Makefile.am and about 10 other places every time there's an API
version bump,
But this is what I was concerned about: _If_ you include the version string
in your Makefile.am you have to change the version at a different place
than k configure.ac. I wonder how you did otherwise.
On your suggestion I have created basic homepages for each of the libraries:
libGenome
http://asap.ahabs.wisc.edu/software/software-development-libraries/libgenome.html
Great - at least for creating the homepage!
For the snapshot you are providing there I get a compile error
g++ -DHAVE_CONFIG_H -I. -I.. -I.. @OPENMP_CFLAGS@ -g -O2 -MT gnFilter.lo -MD -MP -MF .deps/gnFilter.Tpo -c gnFilter.cpp -fPIC -DPIC -o .libs/gnFilter.o
g++: @OPENMP_CFLAGS@: No such file or directory
I guess you are not verifying the existence of MP library...
libClustalW
http://asap.ahabs.wisc.edu/software/software-development-libraries/libclustalw.html
Regarding content I hope you are aware about the license issues we mentioned.
Perhaps Clustalw people are not really happy about this. Please try to
clarify this - even if things are developin in the right direction (license wise).
libMUSCLE
http://asap.ahabs.wisc.edu/software/software-development-libraries/libmuscle.html
As said above: I would prefer if we would be able to convince upstream to
build the library themselved and you just add the link to the upstream
library. (In principle it should be handled the same way for libClustalW
once all license issues are solved.)
libMems
http://asap.ahabs.wisc.edu/software/software-development-libraries/libmems.html
I come back to this once we sorted out the other issues (havn't checked
the code so far).
Please let me know if there's anything else I can do to help.
Many thanks for your cooperation (sometimes upstream developers are not
so cooperative as you are)
Andreas.
--
http://fam-tille.de
Reply to: