Re: Third party code inside Ugene
Hi Yuliya,
thanks again for the helpful and relieable communication.
On Fri, Feb 01, 2019 at 08:15:29AM +0700, Yuliya Algaer wrote:
> Lets start with zlib first: it is easier that way we do not use any custom
> flags, renaming and even have initial support to use system library first.
>
> Check this code from ugene_globals.pri:
>
> # By default, UGENE uses bundled zlib on Windows (libs_3rdparty/zlib) and OS
> version on Linux.
> # To use bundled version on any platform set UGENE_USE_BUNDLED_ZLIB = 1
>
> defineTest( use_bundled_zlib ) {
> contains( UGENE_USE_BUNDLED_ZLIB, 1 ) : return (true)
> contains( UGENE_USE_BUNDLED_ZLIB, 0 ) : return (false)
> win32 {
> return (true)
> }
> return (false)
> }
>
>
> This way you can switch to the system library: bundled sources will not be
> used at all.
I tried this but since in my last packaging (see my other mail) I have
just removed zlib from the source this leads to
Cannot find file: /build/ugene-1.31.1+dfsg1/src/libs_3rdparty/zlib/zlib.pro.
in any case - no matter whether I set UGENE_USE_BUNDLED_ZLIB or not. So
I can easily stick to the patch[1] I've pointed to in my longish mail
from yesterday. So to do the experiment properly I would need to leave
src/libs_3rdparty/zlib/zlib.pro inside the tarball. I could consider
this for the next release of UGENE to be able to drop my patch (for sure
I'd prefer the less patches as possible to minimize maintenance needs).
> So the next steps for Debian packaging could be:
>
> 1) Switch from CMake to qmake build. This is how we build UGENE for
> production.
I've done so anyway since it did not build using CMake (I was not aware
that this is only experimental and switched back immediately once you
confirmed this).
> 2) Try to build it with no bundled zlib. If it works you can completely
> remove zlib folder from UGENE sources for Debian and add zlib-dev as the
> required dependency.
That's done since yesterday evening.
> About Phylip: this is plugin, so it can easily removed from the build &
> source code. While most of the 3rd party tools are run from UGENE as
> external processes, some of them, and Phylip is the one of them, are
> integrated on the source level. Examples of such plugins are: Phylip,
> Muscle, HMMER2, KAlign. Unfortunately we can't replace them with pre-built
> originals because we integrated them on the source level (modified them).
I think I understood this. My question was whether you might be
possibly able to re-check your phylip integration with the latest
upstream source. Besides the license change which would help a lot
regarding packaging there might be some technical progress which could
be interesting for UGENE as well (no matter in what form this might be
integrated).
> The good news is that there are only 4-5 of such plugins, while 90% (like
> BLAST, HMMER3...) are run as external programs.
I've now added all those plugins as recommends[2] to the UGENE package
to make sure the plugins are really installed on user machines. Is
there any way to test that a plugin works? I want to implement
continuous integration tests and so having one simple test for every
available plugin would be a nice enhancement.
> Please let me know if your experiment with zlib is successful. If yes, we
> can try the same with SQLite.
As I wrote in my longish mail yesterday I was able to solve this. However,
if you would enable this more straightforward in the same manner as with
zlib I'd leave the *.pro files and drop my patches. That would be for
sure helpful.
Kind regards and thanks for your support
Andreas.
[1] https://salsa.debian.org/med-team/ugene/blob/master/debian/patches/debian_packaged_libs.patch
[2] https://salsa.debian.org/med-team/ugene/commit/8507dcdd0233a01814d8a34404c1335b9a78d5b2
--
http://fam-tille.de
Reply to: