Errors during installation of KDE for use with Qt Creator

I 'm trying to install KDE in order to use it with Qt Creator.
What I've done so far (my drive letter is G):
1. I installed git in G:\Program Files\Git.
2. I installed cmake in G:\Program Files\CMake (and I put the G:\Program Files\CMake\bin in the PATH variable).
3. I cloned the repository git://anongit.kde.org/kitemmodels.git in G:/kitemmodels
4. I opened the developer console (G:\Qt\Qt5.0.2\5.0.2\msvc2010\bin\qtenv2.bat).
I run (in developer console):

set KDELIBPATH = G:\KDE
mkdir build
cd build
cmake -G "NMake Makefiles" -DCMAKE_DEBUG_POSTFIX=d -DCMAKE_INSTALL_PREFIX=%KDELIBPATH% -DCMAKE_BUILD_TYPE=DEBUG ../

Here I get the error: "CMAke error: the source directory G:/Qt/Qt5.0.2/5.0.2/msvc2010 does not appear to contain CMakeLists.txt".
What am I doing wrong?

You are obviously executing this in the wrong path.

The last part command tells cmake to look for the CMakeLists.txt file in the parent directory of where you currently are.

And apparently that parent directory is G:/Qt/Qt5.0.2/5.0.2/msvc2010 and not G:\KDE

You probably want to do

cd %KDELIBPATH%

before the mkdir command, i.e. create the build directory inside the source directory

Cheers,
_

But the G:\KDE has not yet been created, I thought it would be created after the last command (cmake -G "NMake Makefiles"...).
So, I tried:

set KDELIBPATH = G:\KDE
cd %KDELIBPATH%

And of course it says: the system cannot find the path specified.

Should the G:\KDE have been created? Am I missing some command?

EDIT: it's cd G:\kitemmodels from here.

---

Added after 5 minutes:

At

cmake -G "NMake Makefiles" -DCMAKE_DEBUG_POSTFIX=d -DCMAKE_INSTALL_PREFIX=%KDELIBPATH% -DCMAKE_BUILD_TYPE=DEBUG ../

I got an error:
https://s14.postimg.org/jiioeqkoh/in...dels_err_1.jpg

---

Added after 5 minutes:

I tried from Visual Studio Command Prompt, the same command, now I get this:
Attachment 12356

CMakeError.log:

Quote:

---

Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: cl
Build flags:
Id flags:

The output was:
The system cannot find the file specified


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: cl
Build flags:
Id flags: -c

The output was:
The system cannot find the file specified


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: cl
Build flags:
Id flags: -Aa

The output was:
The system cannot find the file specified


Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: cl
Build flags:
Id flags: -D__CLASSIC_C__

The output was:
The system cannot find the file specified


Checking whether the C compiler is IAR using "" did not match "IAR .+ Compiler":
Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: cl
Build flags:
Id flags:

The output was:
The system cannot find the file specified


Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: cl
Build flags:
Id flags: -c

The output was:
The system cannot find the file specified


Checking whether the CXX compiler is IAR using "" did not match "IAR .+ Compiler":

---

Quote:

---

Originally Posted by panoss

But the G:\KDE has not yet been created, I thought it would be created after the last command (cmake -G "NMake Makefiles"...).

---

yes, I got confused by all your paths.

But as I said: the build directory goes into the source directory.
Or you specify the path to the source directory on the cmake command line instead of "../"

So either change into G:/kitemmodels before creating the build directory or pass G:/kitemmodels to cmake.

Cheers,
_

Source directory is G:/kitemmodels?

This is what I do and get the above mentioned errors:

set KDELIBPATH = G:\KDE
cd G:\kitemmodels
mkdir build
cd build
cmake -G "NMake Makefiles" -DCMAKE_DEBUG_POSTFIX=d -DCMAKE_INSTALL_PREFIX=%KDELIBPATH% -DCMAKE_BUILD_TYPE=DEBUG ../

You are in for a lot of headaches. Just for fun, I tried to build kitemmodels over the weekend.

- You solved the first of your problems by doing the build in a VS command prompt.

- The next problem is that CMake scripts to build kitemsmodels (and probably other KDE libraries, too) depend on "ECM" the "extra cmake modules". You will have to download these from KDE, configure, build, and install them.

- Unfortunately, after you do this and try to generate the Makefiles for kitemmodels again, you will find there is another dependency, that won't be found: glibc

At this point I decided not to keep wasting time and went off to do something more interesting. But if you want to continue down the path, you are going to have to find and build a Windows-compatible version of glibc and all of the other dependencies that CMake will complain about before you can build the KDE library (if in fact you can at all on Windows).

A while ago when I found that the KDE FlatProxyModel class would be useful, I simply adapted the source code for that class into my project rather than trying to build the entire library it came in. Maybe you can do the same.

Quote:

---

Originally Posted by d_stranz

A while ago when I found that the KDE FlatProxyModel class would be useful, I simply adapted the source code for that class into my project rather than trying to build the entire library it came in. Maybe you can do the same.

---

This was my though at the beginning, but then I thought 'if it were so simple, then everybody would do it and there would not exist the necessity (and, thus, possibility) to build it'.

I 'll follow your suggestion! Thank you!

Most of the KDE "Tier 1" libraries in the KDE Frameworks (like KItemModels and KItemViews) depend only on Qt and not other libraries in the Frameworks, so it is not so hard to use individual classes from these libraries at the source code level instead of building the whole library. Qt is platform-independent but KDE is designed for linux, so not all of the KDE code is platform-independent and you might have to do some tweaking to get classes to compile at the source code level on Windows. It usually isn't too hard.

(Edit: Actually, to be more correct, the KDE frameworks are portable, but the extra CMake modules check for dependencies which might only be available on linux by default. In order to make CMake happy so you can use it to build the library, you have to either build the dependencies or modify the CMake scripts to ignore them if the library doesn't actually depend on them).

If you need more than one class, then you may have to bite the bullet and get the CMake build working. However, once you do that, then you should be able to build other Tier 1 libraries as well.

Quote:

---

Originally Posted by panoss

Source directory is G:/kitemmodels?

---

You said that's where you cloned to.

If you use a different directory then obviously change into that.

I don't understand how looking for the top level CMakeLists.txt file can be a problem for a software developer, basic file system navigation skill should be a a given.

Quote:

---

Originally Posted by d_stranz

- Unfortunately, after you do this and try to generate the Makefiles for kitemmodels again, you will find there is another dependency, that won't be found: glibc

---

I am seriously surprised by that, doesn't the Microsoft tool chain come with its own C library?

Using GNU libc would only make sense when building with MinGW.

Quote:

---

Originally Posted by d_stranz

Most of the KDE "Tier 1" libraries in the KDE Frameworks (like KItemModels and KItemViews) depend only on Qt

---

All, not most.
That's the defintion of Tier 1 :)

Cheers,
_

Quote:

---

I am seriously surprised by that, doesn't the Microsoft tool chain come with its own C library?

---

It isn't a Microsoft problem, it is a problem with the extra cmake modules looking for a library with the name "glibc", which doesn't exist in the Microsoft tool chain. I haven't taken the time to look into whether there is a workaround for it. I know from experience it is not an easy library to build with Visual Studio.

The extra cmake modules appear to be designed for building any of the KDE framework libraries in a generic way; they seem to look for many dependencies, whether they are used in the current library or not.

Quote:

---

All, not most.

---

To clarify, the Tier 1 libraries do not depend on each other or libraries in higher tiers in the KDE Frameworks, but they -can- have dependencies on third-party libraries other than Qt. As it says on the KDE site:

Quote:

---

The frameworks are divided into four tiers, based on the kind of dependencies that they have. For instance, Tier 1 frameworks depend on Qt and possibly some third-party libraries, but not on other frameworks.

---

Quote:

---

Originally Posted by d_stranz

It isn't a Microsoft problem, it is a problem with the extra cmake modules looking for a library with the name "glibc", which doesn't exist in the Microsoft tool chain. I haven't taken the time to look into whether there is a workaround for it. I know from experience it is not an easy library to build with Visual Studio.

---

Very strange, as the KDE Windows team builds KDE applications with MSVC as far as I know.

Quote:

---

Originally Posted by d_stranz

The extra cmake modules appear to be designed for building any of the KDE framework libraries in a generic way

---

Right, it is a collection of cmake modules initially developed by KDE and used by projects that need to find various required or optional libraries during their build configure stage.

Quote:

---

Originally Posted by d_stranz

To clarify, the Tier 1 libraries do not depend on each other or libraries in higher tiers in the KDE Frameworks

---

Exactly.
Exactly. Tier 1 Frameworks are essentially additional Qt modules.

Cheers,
_

Quote:

---

Very strange, as the KDE Windows team builds KDE applications with MSVC as far as I know.

---

I'm sure they have, but they have also built and installed all of the third-party dependencies (like glibc) as well, so the extra cmake modules find all of them. If you are trying to bootstrap up to build libraries in the KDE Frameworks (like the OP and me), then you'll have to build and install them too if you follow the cmake route. If the Tier 1 frameworks only depended on Qt there would be no issue, and from what I have seen for some of them (like the KItem* libraries), it is only the cmake modules that are causing the build problems while looking for things that are not actually required for that library.

It isn't an insurmountable problem, it's just a hassle to get it all working. If you aren't familiar with cmake, then what is wrong may not be obvious, and how to fix it maybe even less obvious.

Quote:

---

Originally Posted by d_stranz

I'm sure they have, but they have also built and installed all of the third-party dependencies (like glibc) as well, so the extra cmake modules find all of them.

---

No, sorry, misunderstanding.

What I meant is that they will build with the platform's libc, for MSVC with whatever Microsoft calls theirs.
There are other libc implementations on macOS, BSD, Android, etc, all platforms for which KDE applications are being available.

Any usage of a GNU extension would have been found and either replaced or #ifdef'ed

Cheers,
_

Now I'm completely confused. After building and installing ECM, I issued the following commands from a VS x86 terminal command prompt after cd-ing to the top level of the kitemviews-5.26.0 directory:

Code:

---

mkdir build
cd build
cmake -G "NMake Makefiles" -D ECM_DIR="C:\Program Files\ECM\share\ECM\cmake" ..
nmake
cd ..

---

and it generates and builds the libraries and test programs just fine. The configuration does complain about __GLIBC__ not being found, but unlike my attempt last weekend, cmake seems to ignore it and creates the Makefiles in the build subdirectory. Last weekend it halted at the error when trying to build and run the cmake configuration bootstrapping test programs.

So I have no idea what I might have done wrong the first time through this. My previous comments were based on what happened last weekend, and obviously the KDE kitemviews (and kitemmodels) Framework libraries don't need glibc to build.