Hi Andreas, I spent the last few weeks meandering in the murky marshes of the mugsy source code; It is a monstrosity.
Before answering to your individual points I'd like to stress that I *literally* spend days trying to compile mugsy with seqan 1.3 which comes with Ubuntu 14.04 LTS. A hundred changes in, I gave up. Most of the time, the compiler produces console-filling warnings, overflowing with templates and hiding the actual problems. Next, I built mugsyWGA with the given seqan code, which succeeded. But I have reason to believe the included code is not the one used to produce the binary in the tarball: The seqan library code produces debug output which does not appear in the upstream binary. (Having a library print to std::cerr is extremely fishy.) The "build system" is weird, to say the least. I have nothing against hand-written makefiles per se, but these are simply over-engineered. They try to be platform-agnostic, yet at the same time they include hard-coded paths to locations of libraries on the upstream authors system. Also, the seqan code is piped through a 600-lines-Python-script to produces "forwards". (I don't even …) On 05.04.2016 14:45, Andreas Tille wrote: > On Sat, 25 Apr 2015 08:52:52 +0200 Andreas Tille wrote: >> On Sat, Apr 25, 2015 at 05:30:39AM +0300, johnhom...@gmail.com wrote: >>> I couldn't get it to link, because the authors apparently never heard >>> of autotools. Generally, those handwritten Makefile's just.. made me >>> cry. >> >> +1 +1 (See above) >> >> However, if we really want automake on these old projects we probably >> need to add it ourselves. I did so in the past for living projects and >> it was adapted upstream but I'm not sure here. I am unsure if this is feasible w.r.t. to the weird hacks implemented in the build system. > > The current status is: > > 0. The code seems to be orphaned / unmaintained since 2011. > 1. Mugsy contains a *patched* version of MUMmer 3.20. I took over > those changes to the Debian MUMmer 3.23 package that sounded > sensible I have some extra patches for those tools, making them up to ten times faster. Will commit in due course. > 2. Mugsy also contains a code copy of some files of an old seqan > version. Most of these seem to be not needed and are removed > inside get-orig-source script > > Somehow the removal of the seqan files was a bad idea since when trying > to build against Debian packaged seqan I was running into several errors > which was the reason for my ask for help close to one year ago. For porting mugsy to a newer seqan version you'd need one of the seqan authors from 2011 willing to waste a or two week of their lifes at debugging crazy error messages. > > Since my colleagues stalled the request for the installation of Mugsy I > stopped my effort into this but the topic came up recently again. I > wonder what might be the best way to accomplish the wish to package mugsy: > > 1. Go with the seqan code copy? It has to be patched first, to provide the same functionality as the upstream build (see above). > 2. Find some modern replacement that is better regarding code > maintenance as well as functionality / speed. > I can not really imagine that the last 5 years did not brought > up something better. > My advise: drop mugsy entirely. It is just not worth it, waisting any more time on it. Also, according to the study [1], mugsy has inferior quality to other tools. Best, Fabian [1]: http://www.ncbi.nlm.nih.gov/pubmed/25273068