Andreas Tille wrote:
On Mon, 25 Feb 2008, Aaron Darling wrote:Andreas Tille wrote: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 tobuild the binary linkes against this library. This enhances flexibilityand 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.
That sounds like a sensible way forward. I agree that it would be ideal to avoid code divergence, and hopefully Bob Edgar will agree. I would like to merge my changes with Edgar's muscle 3.7 before sending a patch.
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?
That seems quite unusual. The version which I have found to work without duplicates has identical changes to yours and is committed to the subversion repository. The latest snapshots of libGenome have it already. But of course we need to solve your libGenome snapshot build issue (see below for a possible solution).
What version of automake, autoconf, and libtool are you using? My versions may be somewhat dated, as I've got automake 1.9.2, autoconf 2.59, and libtool 1.5.6. Might you be using any additional options when running these programs that I am not using?
Actually, there is an m4 macro included with libGenome that checks for openmp. This macro gets included when aclocal is run as:On your suggestion I have created basic homepages for each of the libraries:libGenomehttp://asap.ahabs.wisc.edu/software/software-development-libraries/libgenome.htmlGreat - at least for creating the homepage! For the snapshot you are providing there I get a compile errorg++ -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.og++: @OPENMP_CFLAGS@: No such file or directory I guess you are not verifying the existence of MP library...
aclocal -I m4I've included an autogen.sh script with libGenome to take care of running aclocal/libtoolize/automake etc. for potential users of the software. Is it possible that you missed "-I m4" when running aclocal? If you can suggest some standardized way to package m4 macros that obviates the need for "-I m4" then I would be happy to modify the packages accordingly. It's quite possible that I've missed the proper GNU packaging convention here.
I'll reply to the remaining issues in due course... -Aaron