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

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

> 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


[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


Reply to: