On Thu, 13 Mar 2008, Robert Edgar wrote:
I am always happy to work with people who want to use muscle, but the message below is complete greek to me. Somebody needs to explain in language I understand what I might be able to do to help.
Ahh, OK. Just have a look at http://gel.ahabs.wisc.edu/mauve/source/mauve_2.1.1/ There is an archive libMUSCLE-1.0.0.tar.gz. That's why I wrote:
http://gel.ahabs.wisc.edu/mauve/source/mauve_2.1.1/ Aaron, a new library tarball libMUSCLE-1.0.0.tar.gz occured at this location for version 2.1.1 and while you used version 1.0.0 you mention in the file AUTHORS: It contains bugfixes and new features to the original 3.6 code. But upstream now has version 3.7.
I have no idea what bugfixes and new features Aaron has added to muscle 3.6 code - perhaps somebody with more knowledge of muscle code
than me should verify the difference. Moreover I wrote:
So I _really_ like your atempt to build a library and I would love to convince the muscle authors to build their binary linked against this library,
I *really* like Aarons strategy to build separate bundles of libraries that might be used by different projects (just see the download URL above for libGenome and libMems). This is perfectly the right way to go to share code between projects and I would support this strategy at any expense. If I understood things right Aaron needed some code from the ClustalW project for libMems and thus he builded a library from the original ClustalW project. Because there are some licensing issues with ClustalW (that I do not completely understand, but Charles Plessy might comment on this and there is a chance of replacing ClustalW by Muscle I guess Aaron followed his strategy and changed your source that way that a library is builded. This is a very clever idea but IMHO only if this strategy is adopted by you as the original author for your future releases. Otherwise Aaron would always have to to the same work to change your tarball to something that builds the library. To simplify this my suggestion would be that you might take over the automake / libtool stuff into your upstream source to enable building a library from your original tarball. This would mean some extra effort at your side but we would be willing to sort out any problem this might cause to enable you a smooth update of your source. The profit on your side would be that you might get a coworker in Aaron who might send patches for bugs or might add new features because he has a vital interest in having (lib)Muscle in a good shape. Further I wrote:
Could you please clarify things. My prefered way to go would be: 1. Take the latest Muscle upstream source (including patches for gcc 4.3)
This is related to the Debian package which has - if I understood the changelog right - some patches for gcc 4.3. I hope Charles will provide you with all information you need.
2. Choose a new version number.
This is related to the Debian changelog entry: New upstream version, buildable with GCC 4.3 (Closes: #462707) The version number was not increased upstream when the sources were changed. We name this new version in Debian "3.70+fix1". So as a general advide: Please change the version number if the content of your distribution tarball changed. Your users will probably not notice the change which would be a shame.
3. Change the build process using automake / libtools to build a dynamic and static library from muscle code and link the executable against this library.
This is refering to the process I wrote above.
4. Link Mauve binary against this library.
Just ignore this last step - it is intended for Aaron and means that I would suggest him to use your tarball (once it builds the library) instead of providing his own because finally this would lead to a fork.
I'd volunteer to provide any help that might be needed but please try to avoid confusing your users by using different versions that have good chances to drift away from each other.
I hope this is clear. ;-) Feel free to ask again if anything remains unclear. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]