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

Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))



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, johnhommer@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


Reply to: