[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]


On Fri, 21 Mar 2008, Aaron Darling wrote:

I have just completed merging the changes between muscle 3.6 and muscle 3.7 into the libmuscle library. It didn't take very long but I've been busy with other things so it took a long time to get around to doing it. Be aware that I have only done minimal testing since I don't have a muscle test-suite. While merging the changes, I noticed that 3.7 has fixes for a few of the issues I discovered in 3.6 and fixed independently. That reassures me I wasn't off-my-rocker when making changes. If you're curious Robert, a precise list of bugfix-type changes can probably be gleaned from the subversion repository for libMUSCLE. I've been using subversion religiously.

Sounds very good!

More to the point, I have created a set of diffs against the 3.7 codebase, which when applied will merge in all of my changes to the 3.7 code:

Just downloaded and I will see how we might be able to base a Debian
package on it.

If you look through the patch, please do not be intimidated by the large number of changes. Many changes are storage class changes to static and global variables to put them in thread-safe storage. You'll see lots of variables wrapped with the TLS class. When compiled with OpenMP, the TLS class provides a thread-local version of the variable, when compiled without OpenMP, the class effectively does nothing and the compiler should optimize it away.

This sounds like reasonable changes for any user of Muscle.

Please note that the Makefile.am included with libMUSCLE also builds the muscle binary by default. That may need to change if it is to be packaged exclusively as a library for debian.

No this is precisely what we really want because currently we have
just the binary and this should be provided for our users but having
the library as a separate package and the binary linked against this
library is exactly the right way to go for the Debian package.
Many thanks for working on this!!!

Robert, I would be delighted if you would consider basing future muscle releases around the library refactorization. Please let me know what else I can do to facilitate it.

I would totally support this.

BTW, Aaron, libGenome is now an official Debian package as you can see at


Moreover I noticed that we might get some name space polution with Mauve:
Please have a look at


I do not know this other mauve project but wt least we might possibly
have to change the package name of your Mauve in Debian in case we
can not convince the other maintainer to change the name.  Could you
perhaps suggest a useful name for the Debian package?  I'd consider
something like wisc-mauve or something like this reasonable, but perhaps
you have a better suggestion.  Once we are at it: Do you have any
hint for my problem with a missing jar file when trying to build Mauve?

Happy Easter



Reply to: