HI,

Running the final build on kexi gives the following output:

Code: Select all

CMake Error at CMakeLists.txt:2 (simple_option):
  Unknown CMake command "simple_option".

If I comment those lines out (which seemed a reasonable option) in ~/kde/src/kexi/CMakeLists.txt then the situation is unaltered which might indicate that I am not looking at the correct CMakeLists.txt . I see "simple-option" in the CMakeLists.txt for kdb among others. (There are two instances of "simple_option" in the kexi CMakeLists.txt so I assume that explains the ':2').

Before I totally wreck this, is there a simple solution here?

Best
Ian

Hi,

I decided to comment out all instances of 'simple_option' under /kde/src/. It seemed a reasonable option in that I would learn something from the behaviour, there is a reason for those lines in the CMakeList files so I did not expect a build.

What I learned was that this is a recursive matter, it of course did not build, but threw up a new error

Code: Select all

CMake Error at CMakeLists.txt:172 (ecm_create_qm_loader):
  Unknown CMake command "ecm_create_qm_loader".

So this could go on ad infinitum with more and more 'unknown' CMake commands. Obviously I have made some error prior to this stage. So back to the drawing board, delete all, start again. I will try one more time on this machine. The original decision to build was made so that I could help support kexi through bug reports on the bleeding edge as well as have a more uptodate version than Mint provides. So I am more than sorry that I find myself in this situation many many months after upgrading to Mint18 that I still cannot achieve any measure of success with kexi3.

I have one more machine that needs to be updated and I will move that from Mint to one of the distros with updated kde support like KDE Neon or openSUSE, whatever. I am not time-wise in a position to upgrade this particular machine right now, there is so much else to it than just opping in the CD as I am sure you know so will likely drop back to 2.9

I think that kde/kexi should make it clear on site that the Ubuntu/Mint LTS versions carry a penalty in respect of their long term support in the way of outdated versions no longer supported by kexi.

best
Ian

Thanks for trying inksi. No commenting out any code is needed.

0. Have you installed extra-cmake-modules package (ECM)?
1. What are exactly commands used to build KEXI?
2. What's your cmake version.
3. What is your KEXI source code version (git log -1)?
4. Have you built and installed KDb, KProperty and KReport already?

Yes it's apparent that I complain about Ubuntu's unacceptable approach to software packaging. Appimages of Flatpacks can solve this, which is a shame that we, software developers have to fix this basic thing. Also easier way of building can help. (it is already quite easy on Windows!

0. Have you installed extra-cmake-modules package (ECM)?

Yes. I checked the package manager and we have 5.18.0
we also have ~/kfe/share/ECM and ~/extra-cmake-modules
surely something is redundant here?

1. What are exactly commands used to build KEXI?

Code: Select all

~/kde/build/kexi $ cmake -DCMAKE_INSTALL_PREFIX=$HOME/kde/inst5 $HOME/kde/src/kexi -DCMAKE_BUILD_TYPE=Debug

2. What's your cmake version.

3.5.1

3. What is your KEXI source code version (git log -1)?

Code: Select all

inksi@anyte ~/kde/src/kexi $ git log -1
commit f27e20e7393a6b3d1517c9b6aeba700fe21fd07c
Merge: 87f3b8d d9c7ab2
Author: Jaroslaw Staniek <staniek@kde.org>
Date:   Mon Apr 9 16:23:15 2018 +0200

    Merge remote-tracking branch 'origin/3.1'

4. Have you built and installed KDb, KProperty and KReport already?

Here we come to the crunch. The answer is a qualfied yes
Yes, I did build them, No, I am certain that the builds were not successful
This is how I built them

Code: Select all

~/kde/src/kdesrc-build/kdesrc-build kdb
~/kde/src/kdesrc-build/kdesrc-build kproperty
~/kde/src/kdesrc-build/kdesrc-build kreport


I note that each invocation of the above attempts to build some 78 items, but only extra-cmake-modules and phonon, plus one of kdb, kproperty, or kreport actually get built - according to the final output. The unbuilt items typically show something like this:

Code: Select all

Building baloo from frameworks (75/78)
   No source update, but the last configure failed
   Updating baloo (to branch master)
   Source update complete for baloo: no files affected
   Preparing build system for baloo.
   Removing files in build directory for baloo
   Old build system cleaned, starting new build system.
   Running cmake...
   Unable to configure baloo with CMake!
   Unable to configure baloo with KDE


Further ~/kde/src/successfully-built only ever shows extra-cmake-modules, phonon, and the last one of kdb, kproperty, & kreport built as mentioned above so obviously this is not intended to be cumulative.
Finally, ~/kde/build/kdb|kproperty|kreport have no content, thus the conclusion is that they are not built.

So not suprisingly at this stage attempting to build kexi as (1) above results in failure with the 'simple-option' error described in my earlier post.

Conclusion. Something is wrong. If this points to any one thing clearly I am all ears else I have documented my steps and could clean out ~/kde for another attempt.

best
Ian

If kdesrc-build was used to build these repositories then it should be also used for building KEXI itself. I am not a user of kdesrc-build for a long time so would be unable to advice on best technique. Building KEXI is a standard task of building software so I would be concerned what the problem is why wider KDE community would not be able to participate in helping you. For example at viewforum.php?f=305. Please do not see that as redirecting but I see it that more people should be involved in the helping out than the author

Perhaps using the kde-devel@kde.org mailing list is also idea on development help?

Jaroslaw, hi.

I think you have hit the nail on the head with my using kdesrc-build alongside the traditional cmake command line approach. I will move to correct that, hopefully with better results.

I understand the need to separate queries to the appropriate source where most help can be given. Thanks for the advice on where to look. No problems with this.

best
Ian

Later, 30May 2018

I officially give up on this task. Mint is too far behind.