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