New portfile for SeqAn

[tre@…]

Hi,

I would like to submit a new portfile for SeqAn, the scientific library for sequence analysis developed in our group. For more information see ​http://www.seqan.de.

Thanks and kind regards,
David Weese

[ryandesign (Ryan Carsten Schmidt)]

The Milestone field is not used for port tickets.

[okohlbacher@…]

Is there any chance of this ticket moving forward any time soon? I would really love to see this included in macports... and it is also a dependency for other projects. What is the proper procedure for this anyways? will this be assigned eventually?

Cheers,

Oliver

[tre@…]

Hi,

I just updated the port file since we moved our homepage and we fixed a compilation error with clang++. Could you please include SeqAn into the ports repository (ports/science/seqan)

Cheers, David

[ryandesign (Ryan Carsten Schmidt)]

Sorry this took so long. Usual procedure is if your ticket is not handled in a timely manner, please remind us by writing to the macports-dev mailing list.

This'll take awhile to build; I'll check it in the morning.

[nerdling (Jeremy Lavergne)]

It looks like this package will pull in python and boost if they're available.

[nerdling (Jeremy Lavergne)]

A few nitpicks:

• why not have the name be lower case like the distfile?
• should set distname instead of distfiles
• maintainer addresses aren't obfuscated

[tre@…]

Yes you are right, we have a python script to generate forward headers (will be removed in the release 1.4). I'm going to add a dependency for python26. Boost will be recognized by our build system but isn't used by the applications in the 1.3.1 release.

[nerdling (Jeremy Lavergne)]

Replying to tre@…:

I'm going to add a dependency for python26.

Is it possible that we can use python27 instead of python26? Most applications are on python27, so it helps avoid installing multiple versions.

Boost will be recognized by our build system but isn't used by the applications in the 1.3.1 release.

Can we disable the opportunistic inclusion of Boost? I don't see a WITH_Boost or similar conditional in the CMakeLists.txt. Would simply adding -DBoost_FOUND=FALSE to configure suffice?

[mf2k (Frank Schima)]

It is best to make variants for different versions of python.

[nerdling (Jeremy Lavergne)]

Replying to macsforever2000@…:

It is best to make variants for different versions of python.

Not only would the dependency need to be changed but the CMake paths for that Python likely need to be set by the Portfile as well.

[tre@…]

Mmh. Doesn't come Mac OS X with a preinstalled python binary? Do I really need a dependency? And if, I'm not really sure how to say cmake that it should search for a certain python version, I can only see that one can access the version number of the interpreter found.

[nerdling (Jeremy Lavergne)]

Replying to tre@…:

Mmh. Doesn't come Mac OS X with a preinstalled python binary? Do I really need a dependency?

You don't absolutely have to but what happens as various versions from MacPorts are found, Python 2.4 through Python 3.2? If you don't mark a dependency on a MacPorts one and it was used, then uninstalling that Python could break your program since it may expect it (do you use Python outside of building?).

And if, I'm not really sure how to say cmake that it should search for a certain python version, I can only see that one can access the version number of the interpreter found.

In KDE we do this by setting CMake's variables for the path of library and includes directories:

-DGETTEXT_INCLUDE_DIR=${prefix}/include
-DGETTEXT_LIBRARY=${prefix}/libgettextlib.dylib

[tre@…]

Ok,

now there is a dependency on python2.7 and the path to the binary is given to cmake. I removed all Boost/TBB/CUDA detections from the build system and repackaged the seqan-1.3.1 release, as they were not used by the released applications. Please have a look at the new porfile

Cheers, David

[tre@…]

SeqAn portfile

[nerdling (Jeremy Lavergne)]

Looking much better on my end.

The only other CMake-related question I have is the OpenMP tests. If that's openmpi, it's available in MacPorts and, if you know it's used, we should depend on it as well.

A side note, since you modified the distfile, we now have to add this to the portfile (I have it added in my copy I'm about to commit after feedback on openmpi).

dist_subdir         ${name}/${version}_1

[tre@…]

OpenMP is the acronym of open multi-processing, a language extension built in nearly all current compilers for multi-core shared memory parallelization. The test for OpenMP simply turns the extension on if the compiler provides it. Some functions are then parallelized. OpenMPI is something completely different and denotes the Message Passing Interface for parallelization over multiple cluster nodes.

[nerdling (Jeremy Lavergne)]

Alrighty, thanks for the clarification :-)

Committed the portfile in r90784.

[ryandesign (Ryan Carsten Schmidt)]

I see that while I was sleeping and waiting for the port to finish building, much has happened in this ticket. I'll open a new ticket for the remaining issues I was going to address.

To comment on some of the above:

Replying to snc@…:

why not have the name be lower case like the distfile?

There's nothing wrong with mixed-case port names; they may even be preferable if they more accurately represent the proper name of the software. The port name is what the user interacts with; the user doesn't care at all what the distfile name is, so the case of the distfile is not a valid reason for choosing the case of the port name. Even the name of the distfile needn't dictate the port name, though it often does.

Once upon a time the use of uppercase letters in port names was discouraged because there was a bug in MacPorts where uninstalling a port would fail if you did not type the port name with the correct case, and users are more likely to type the port name in all lowercase. But that bug was fixed years ago. Today, we have a new bug where pre-compiled archives are not fetched if you don't type the port name with the correct case, but that has already been fixed in trunk and I'm going to merge it to the 2.0 branch soon for inclusion in MacPorts 2.0.5.

So there's no particular reason why mixed-case port names should not be used. However, now that the port has been added as "seqan", I suppose we should leave it that way.

Replying to snc@…:

A side note, since you modified the distfile, we now have to add this to the portfile (I have it added in my copy I'm about to commit after feedback on openmpi).

dist_subdir         ${name}/${version}_1

Since this is a new port that had never been committed before, this was not necessary, but it isn't harmful either. But I would strongly encourage software developers never to repackage a release like this. See wiki:PortfileRecipes#stealth-updates.

[tre@…]

Replying to snc@…:

Alrighty, thanks for the clarification :-)

Committed the portfile in r90784.

Thanks for submitting.

[tre@…]

Replying to ryandesign@…:

So there's no particular reason why mixed-case port names should not be used. However, now that the port has been added as "seqan", I suppose we should leave it that way.

That's just fine.

Replying to snc@…:

A side note, since you modified the distfile, we now have to add this to the portfile (I have it added in my copy I'm about to commit after feedback on openmpi).

dist_subdir         ${name}/${version}_1

Since this is a new port that had never been committed before, this was not necessary, but it isn't harmful either. But I would strongly encourage software developers never to repackage a release like this. See wiki:PortfileRecipes#stealth-updates.

I was thinking the same. However, in future releases we will take care of stealth updates.

Thanks and regards, David