search

gpertea / gclib

GCLib - Genomic C++ library of reusable code for bioinformatics projects
Other
33 stars 13 forks source link

Makefile ready for installing gffcompare #4

Closed bernt-matthias closed 5 years ago

bernt-matthias commented 5 years ago

The current Makefile does not allow to build gffcompare. Some extra .o / .so files need to be created.

For a recent bioconda package I commited the following patch to get it (hopefully running):

https://github.com/bioconda/bioconda-recipes/pull/12416/files#diff-bf53084914598c421a598e57f68431ae

.. maybe include just all objects .. ?

gpertea commented 5 years ago

I appreciate your work on this -- and I apologize for these complications, but gclib is not supposed to be built as a standalone object library (despite the misleading name). Is there anything else besides gffcompare (maybe gffread) referencing gclib there? The way I've envisioned the common code in gclib being used is by selectively building only the needed object files as specified in the Makefile of the main program using that gclib code (i.e. the Makefile of gffcompare, or of gffread etc.). The Makefile in the gclib directory was only used for my own personal testing and it was never meant to be distributed with the code -- and definitely not meant as a way to build/package the gclib code as a shared object library. The various prep_*.sh scripts in the gffcompare and gffread repositories show how the necessary source files are pulled from a common gclib directory in order to build the main programs. I know this involves some compiled code redundancy (as opposed to using shared object files) but it seemed safer for me this way as I can change/add features to the gclib code without worrying that previously deployed programs may break etc. So at this time I would strongly suggest that gclib should NOT be distributed separately and rather have the bioconda recipe mimic the behavior of prep_linux.sh/prep_mac.sh for each of the programs employing the gclib code.. This involves first pulling the gclib source code from github in a separate directory without building it and then retrieving and building the actual programs using (parts of) that source code as specified in their respective Makefiles (completely ignoring the Makefile in the gclib directory, that's not supposed to be there anyway).

bernt-matthias commented 5 years ago

Thanks for the detailed comments. I will try to change the conda package for gffcompare accordingly .. and maybe we remove the gclib from bioconda.

I guess this then boils down to a documentation problem, since the "Building from source" section doesnt mention the prep scripts.

gpertea commented 5 years ago

I am not sure why this would be a "documentation problem", I believe the provided instructions work as a simple guide for manually building the program(s) from source/github, aren't they? And please note that the documentation does not instruct the user to build gclib separately (i.e. to make use of the Makefile in the gclib directory).

Also, the documentation does not mention the prep*.sh scripts because those were only meant as helper scripts for myself, for automated packaging of the program(s) for source and precompiled binary distribution on our website (as seen here: https://ccb.jhu.edu/software/stringtie/gff.shtml#gffcompare_dl). Most of the target audience of these programs would just want to either get the precompiled binaries, or, if they prefer they can fetch the source and build the program as described in the documentation. They do not need to use the prep*.sh scripts unless they want to repackage the program.. But I am glad if these scripts are also found useful by a packaging system like bioconda!

Thank you for your work on maintaining bioconda packages, it's such a great packaging system (using it myself occasionally), and I realize (and sorry for) the difficulty of dealing with quirky developers like myself with poor/non-standard software packaging/building habits.

bernt-matthias commented 5 years ago

My problem was that I downloaded the releases provided by github. Then the path names for make did not match. Now that I understood it everything is fine :)

I realize (and sorry for) the difficulty of dealing with quirky developers like myself with poor/non-standard software packaging/building habits.

Perfectly fine. Everybody is free to do whatever he likes to do. You have been very helpful. Thanks.