Create build_tarballs.jl for norMD

[diegozea]

Description:
This PR adds a build recipe for norMD (normalized Mean Distance) version 1.3, a tool from the AQUA suite used to assess the quality of multiple sequence alignments (MSAs).

The build process compiles several executables; however, only the normd binary is installed.

References:

• Thompson, J. D., Plewniak, F., Ripp, R., Thierry, J. C., & Poch, O. (2001). Towards a reliable objective function for multiple sequence alignments. Journal of Molecular Biology, 314(4), 937–951.
• Muller, J., Creevey, C. J., Thompson, J. D., Arendt, D., & Bork, P. (2010). AQUA: automated quality improvement for multiple sequence alignments. Bioinformatics, 26(2), 263–265.

[stemann]

I would suggest to use a less concise name as the tool is for a specific field (bioinformatics, MSA), e.g.,

Suggested change

	name = "norMD"
	name = "AquaMSANorMD"

Even adding MSA to disambiguate among all the "Aqua"'s out there (Aqua.jl, Aqua macOS GUI, JetBrains Aqua, ... https://github.com/search?q=aqua&type=repositories&s=stars&o=desc ).

[diegozea]

Hi! Thanks, I understand :) Can it be NormalizedMeanDistance ?

[stemann]

From my perspective, with a background in Computer Science, and not in Bioinformatics, I would be more comfortable with a name completely without field-specific abbreviations, i.e., I would really be most comfortable with a name like

AquaMultipleSequenceAlignmentNormalizedMeanDistance

But I'm OK with AquaMSA as the prefix if that is preferred, but I think there should be a prefix to disambiguate among other interpretations of "NorMD" or "NormalizedMeanDistance".

I do not think NormalizedMeanDistance only makes sense for MSA (with sequence referring to DNA/RNA sequences, I presume...). E.g., in Computer Vision, it is common to look at the IoU (intersection over union) distance between object detections, and then compute mAP (mean average precision) based on an IoU threshold. I would not expect everyone in the whole world (Julia world) to understand, or even accept, computer vision-specific terms as universal terms.

[diegozea]

I believe the package name should ideally match the tool's name, following the usual [convention](https://docs.binarybuilder.org/stable/building/#Name) for JLL packages.
After reconsidering, since the upstream AQUA project provides the norMD tool, I think it would make more sense to name the package AQUAnorMD.
This keeps the name closely tied to the upstream project while being simpler and improving discoverability.
What do you think?

[diegozea]

In the last commit, I changed the name from norMD to AQUAnorMD to better align with the upstream project and improve clarity.
Should the file also be renamed to AQUAnorMD and moved into the A/ folder to reflect this new naming?

[giordano]

By "not necessarily" I mean that they're specifically not checked for naming rules.

[diegozea]

Thanks for the feedback and the thoughtful discussion.

I'd like to explain why I still think norMD is the most appropriate name for the JLL package:

1. There is no other standalone software named norMD. So, currently there are no naming clashes, and such conflicts are unlikely in the future — especially since the casing (norMD) isn’t standard in Julia.

2. I really like the idea of JLL packages being named after their actual software or suite. It helps a lot with discoverability. For example, that’s how I found useful tools like MAFFT_jll. I wouldn’t have found them easily if the name had been something like MultipleAlignmentUsingFastFourierTransform_jll.

3. While I’ve taken the implementation from AQUA because it’s the only publicly accessible one — available via wget — the norMD tool was published independently before AQUA. In fact, to get other versions, you'd need to contact the paper authors directly. So AQUA is just bundling norMD, not the origin of it. Future versions of the tool could appear outside AQUA too. So, I would prefer not to tie the package name to AQUA.

Let me know what you think — I’m open to discussing further, but I believe keeping the norMD name fits the conventions and benefits users the most.

[stemann]

Regarding 1, when I go looking for “norMD”, I find (in the following order):

• https://rdrr.io/github/EvansLaboratory/OBIF/man/normD.html
• normD seems to have been a C thing since sometime in the 1990’s (or before): http://dbwww.essc.psu.edu/lasdoc/user/normd.html - seems to be an executable written in C or Fortran

(no trace of the aqua/msa normd)

Regarding 2: In contrast, all of the first 10 hits from
Google for mafft seems to be for bioinformatics multiple alignment FFT of some DNA/RNA sequences.

Regarding 3: It makes sense not to link the package to AQUA if they are merely bundling it.

[diegozea]

Note that the mentioned normD and normd do not clash because of the different casing ;) Also, normD is an R subroutine, so it would not be a JLL package.

[stemann]

I would say that casing is too brittle to rely on for disambiguation.

And yes, I don't see the R package command becoming a JLL, it was more to show that there were (more common?) interpretations of what "normd" might be.

[giordano]

This code is so bad, it's a miracle it was ever possible to compile it.

[diegozea]

Yes! I tried a similar setup early unsuccessfully, so at some point I desisted and chose to allow only the list of platforms for which I was able to compile it :/

[giordano]

Also the Makefile is complete rubbish and doesn't consistently use the CFLAGS variable for compiling all the source code.