Hi Fabian, On Tue, Apr 19, 2016 at 12:29:59PM +0200, Fabian Klötzl wrote: > 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 …)
Thanks a lot for the energy you have put into this code. > 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, [email protected] 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. I also think that it might be a waste of time adding automake to a dead project. > > 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. Cool. Just ping me for sponsering. > > 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. We can't probably gather a sufficient amount of money to bribe anybody to do this horrible job. > > 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). Once there were patches posted to this list[2] - are you aware of these? > > 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. Thanks for the summary I'll foreward for further discussion. Kind regards Andreas. > [1]: http://www.ncbi.nlm.nih.gov/pubmed/25273068 [2] https://lists.debian.org/debian-med/2015/04/msg00036.html -- http://fam-tille.de
