Conversion to the cmake building system. #5

Still lot of work...

Remove -UTQT_NO_COMPAT...done
Look for other definitions
Add a man page...done
check if kontact(maybe header check...) is installed before BUILD_KONTACT_PLUGIN...done
file-integration, miss basket.magic.mgc...done
symbols visibility...not quite yet I believe.

Shimata! gpgme.pc is only available starting with gpgme-1.13.0...done

Oops, on Debian 7.x (Wheezy) is libgpgme11-dev 1.2.0 😉

Remember when we had to make kgpg work with gpg2? Then I did pinentry-tqt and since then I am on their mailing list. No one will ever use gpg1 now or in the future - my 5cent to this topic.

Do not forget that we do not choose the version of gpgme, but that it is given by the distribution for which the package is built. Therefore we must be ready to build with all versions used.

For kgpg we decided that old version will not be supported.

Gnupg do not support the older version either. One building for wheezy or jessie should use an older version of TDE and can not expect latest to build.

This is how I understand the problem. I just share my view, but may be in this particular case you are right - I do not know.

As you can see, we support a very wide range of distribution versions. This means that it is possible to build a current version of TDE for all the distributions that are still supported.

At the same time, if there is no serious obstacle, while adding support for new version of libraries, we are trying not to break building with older versions.

-D WITH_LIBART=OFF --> FTB

In file included from /home/cethyel/Public/APPLICATIONS/basket/build-basket/basket/src/kiconcanvas.cpp:45:0:
/usr/include/ksvgiconpainter.h:24:36: fatal error: libart_lgpl/art_render.h: No such file or directory
compilation terminated.

gone with last commit: 6b78c44383

One can notice that the icons in the 'tags' folder are installed twice.

Once in ../share/apps/basket/icons/crystalsvg/16x16/actions/
then in ../share/icons/crystalsvg/16x16/actions/

Maybe one install is enough, to be continued...

@SlavekB I've remove the tags icons in ../share/apps/basket/icons/crystalsvg/16x16/actions/, please give some feedback when you've got the time.

@cethyel Great work! 👍

I did some test on Gentoo here and already created some ebuild for your CMake conversion.

You are right, that without SVG support, aka libart_lgpl, I get some FTBFS too.

But building with and without aRts, handbook, translations, kontact and crypt works perfectly for me. I also started Basket and it seems all is working fine!

@Chris Thanks for your feedback 😄

I just re-read the the discussion and noticed that this problem about libart should be fixed now? Maybe I have to re-test, because it wasn't for me. Even with the commit Slavek did back then.

What ever it was, it seems to be gone. I can confirm all builds fine for me now, with and without libart. Maybe you rebased your branch since then? But, great! 👍

Maybe you rebased your branch since then?
Yes, Slavek fixed It in the code, then I could carry on.

I tested it and made a few adjustments:

Using find_path to determine GPGME_INCLUDE_DIRS seems wrong to me. If gpgme is installed with a non-standard path, then find_path would not find the header file, while gpgme-config --cflags returns the necessary value. If header file is on the standard path, then gpgme-config --cflags returns nothing, which is also the correct way.
TQTDCOPIDL and TQTDCOPIDL2CPP need not be set, since detection is already performed in FindTDE. At the same time, the names used lacked the correct path to the binaries, which could lead to FTBFS.
Added separate targets for generating kidl and stub files, because this is useful to avoid possible multiple execution of commands.
Fixes related to automatic ASCII cast.
Added support for LINGUAS for listing translations to install.

I tested building on Debian Bullseye with TDE 14.1.0 and Debian Wheezy with TDE 14.0.8 – both successfully. If you agree, I suggest we do squash for cmake-related commits into one. ASCII cast-related fixes will be a separate commit.

Since I often use Basket, I immediately tested the functionality and found no problems.

@cethyel this looks like another great job from you!

Looking for <gpgme.h> header seemed a save bet to me, relying on "gpgne-config" for the headers in addition to the libs, sure is better.

I'll be testing this later today...

comments:

I still believe that the option BUILD_ALL should be "ON" by default since the kontact plugin, the doc and the translations are the real optional builds.
In file-integration, few magic files ought to be created at build time, the "file" program is needed for that purpose. Is It relevant to look for that executable before then display a message? I don't know which package provides "file" actually...
I've got kind of red fish memory but since I switched from the default WITHOUT_ARTS to WITH_ARTS, shouldn't this be reflected accordindly in the automake building options? (can't test right now)
Out of curiosity, does building with libart_lgpl bring anything new?

Looking for <gpgme.h> header seemed a save bet to me, relying on "gpgne-config" for the headers in addition to the libs, sure is better.

I'll be testing this later today...

comments:

I still believe that the option BUILD_ALL should be "ON" by default since the kontact plugin, the doc and the translations are the real optional builds.

Yes, it seems to make sense that at least small applications have BUILD_ALL set to ON by default.

In file-integration, few magic files ought to be created at build time, the "file" program is needed for that purpose. Is It relevant to look for that executable before then display a message? I don't know which package provides "file" actually...

This is a good tip – find_program could be used here.

I've got kind of red fish memory but since I switched from the default WITHOUT_ARTS to WITH_ARTS, shouldn't this be reflected accordindly in the automake building options? (can't test right now)

Thank you for reminding! I'll prepare the patch.

Out of curiosity, does building with libart_lgpl bring anything new?

At first glance, I did not notice the difference. But it's possible that I wasn't attentive enough.

Added other small changes:

WITH_ARTS for automake build.
The config.h file is preferable to include in CPP files instead of in H files, as this is usually the first file to be included.
In the UI file, includehint has been changed to include, but the inludehints tag itself has been forgotten.
Use the FILE_EXECUTABLE that we checked above.

I did rebase to the current HEAD and regroup the patches so that the things that are related are together.

Please, you can do the final test.