[fetzerch]

Hey everyone,

in the past weeks I've helped out a bit with the CMake based build system that is being developed in FernetMenta's repository.
Since there is currently no tool in place to track the progress and open tasks I'm starting this thread here.

Introduction
Kodi is cross-platform software, but uses native build systems for all its supported platform. This leads to an enormous amount of work to keep those build systems in sync.
Because of this notspiff, wsnipex, FernetMenta, Montellese, et al. are working on a generic CMake based build system that can be used cross-platform.
Instead of manually maintaining Autotools, XCode and Visual Studio project files, CMake is able to generate those project files and build configurations, source files, compiler & linker flags, libraries and other build options are then managed in one generic place. In addition CMake can also unify and simplify the dependency management.

Even though a huge amount of work has already be done by the guys, there is still a lot of work to do (especially support for the missing platforms). Yep, Kodi's build process is quite complicated.

Current Status
This lists the current platform status (CMake generators in parentheses).

- Linux (Makefile): done
- Raspberry Pi (Makefile): done
- Windows (NMake, Visual Studio 14): done
- OSX (Makefile, Xcode): done
- IOS (Makefile, Xcode): done
- Android (Makefile): done

Currently CMake 3.1 is required, but it's likely that we have to bump to an even more recent version. Luckily it's typically easy to install newer CMake versions on most platforms.

Jenkins is now able to build Kodi for all platforms and is currently configured to do a nightly build with CMake.

Instructions
I've put together a readme file in the repo for the build instructions: https://github.com/xbmc/xbmc/tree/master.../README.md

TODOs
Here's the list of open points and known issues. Not really sorted yet, but it's a start.

Generic
- Some functions and macros have manually implemented parameter handling. Use CMakeParseArguments instead.
- Check if all build types work (CMAKE_BUILD_TYPE) and print warnings / error messages if a non supported build type is selected.
- Modernize the FindXXX.cmake modules and start to use imported targets (Target::Target).
- Replace the hand crafted optional/recommended feature list with FeatureSummary
- Create targets for the projects built with externalproject_add. This should allow us to remove the add_dependencies calls. example
- Change in treefiles doesn't trigger a cmake rerun when starting a build.
- Options and optional dependencies not applicable for a certain platform should not be listed.
- copy_if_different is very slow (especially on non SSDs) because it byte compares the files. For our purpose it would be enough to check the timestamps. This thread explains a solution using custom commands. Unfortunately file based dependency support has some issues so that it's not that easy to implement with just one function (as our copy_file_to_buildtree function). (PR9561)
- Add headers and other files to the libraries (this will improve IDE support. Some IDEs only show headers with the same name as source files.

Windows
- Build Texturepacker. (now that missing giflib static library is awailable in the dependencies)
- Use ExternalProject_Add to compile the mingw dependencies (needs: https://github.com/fetzerch/xbmc/commit/...t-15277878)
- Additional libraries, nodefaultlibs and delayedloadeddlls, are currently hardcoded in macros/windows.cmake and applied to all targets. The cleanest way would be to have a Find Module for them and they have to be specified only for the main Kodi executable.
- Check (and fix) options. CMake offers now the possibility to disable certain features on Windows like it was possible with the Autotools project on Linux. Not sure if this works properly or if some macros are still set incorrectly.
- Replace #pragma comment(lib) by the properly found libraries.
- Make sure that compiler and linker options are the same as in the Visual Studio project and fix remaining warnings.
- The compiled exe does not start from the folder where it's built (Debug or Release). (FIXED: KODI_HOME has to be set to the build directory)

Original PR: https://github.com/xbmc/xbmc/pull/9083

CMake Documentation
CMake has progressed a lot in the past years but many tutorials and documents that can be found in the internet are highly outdated. Hence here's a list of useful documentation material:

- CMake: The CMake Buildsystem
- CMake: How to write Find Modules
- Stephen Kelly - The What, Why and How of Modern CMake
- CMake Introduction and best practices

Cheers,
Christian

[Tolriq]

You should have started with https://github.com/notspiff/kodi-cmake I think

[fetzerch]

Thanks, I'm aware of that. The others have merged https://github.com/notspiff/kodi-cmake into https://github.com/FernetMenta/xbmc (with some adaptions).
So far I've mostly done fixes for Linux and the generic part + worked on getting it built on Windows. Spiff is aware of what's happening and fortunately he's helping quite a lot in explaining the existing framework (thx btw ).

[jediry]

Has anyone started working on cpack integration (i.e., for building the installer packages)? If not, I might try to tackle converting the existing NSIS script over to cpack.

[fetzerch]

Using CPack to create the installer is definitively the way to go. As far as I know Hudokkow (h.udo) has started with it - he has done the cpack work already to create debian packages for Linux. I'll point him to your post since it doesn't seem he has pushed anything for windows yet. He's currently on vacation, so it might take a bit until he replies.

- CPack for .deb files: https://github.com/xbmc/xbmc/pull/9987

[h.udo]

Has anyone started working on cpack integration (i.e., for building the installer packages)? If not, I might try to tackle converting the existing NSIS script over to cpack.

Nope, go right ahead. CPack for Windows is on my todo list but I first want to get rid of all the batch files and have a pure CMake solution. Work done so far is at https://github.com/hudokkow/xbmc/commits...buildsteps but I just realized I forgot to push a couple of commits with fixes I have on my office machine.

I'm on vacation until the 29th and I'll be happy to assist in whatever I can after that. Just ping me on github or PM me your github handle so I can follow the work.

Thanks for looking into this.

Have fun!
Cris

[Martijn]

Has anyone started working on cpack integration (i.e., for building the installer packages)? If not, I might try to tackle converting the existing NSIS script over to cpack.

Nope, go right ahead. CPack for Windows is on my todo list but I first want to get rid of all the batch files and have a pure CMake solution. Work done so far is at https://github.com/hudokkow/xbmc/commits...buildsteps but I just realized I forgot to push a couple of commits with fixes I have on my office machine.

I'm on vacation until the 29th and I'll be happy to assist in whatever I can after that. Just ping me on github or PM me your github handle so I can follow the work.

Thanks for looking into this.

Have fun!
Cris

Can i ask what the big advantage is for cpack that basically just generates the NSIS file we already have which is tweaked to whatever we need and you still need NSIS in the end?
Looking at it makes it just just more difficult to get it as we currently have and from the docs not everything is possible. So imo don't bother.

[jediry]

Can i ask what the big advantage is for cpack that basically just generates the NSIS file we already have which is tweaked to whatever we need and you still need NSIS in the end?
Looking at it makes it just just more difficult to get it as we currently have and from the docs not everything is possible. So imo don't bother.

The advantage of porting the NSIS stuff to use CPack is that it's then possible to use the same file install logic with a different package format. Specifically, for producing a .appx package for UWP. Else, we have to maintain the NSIS and .appx file structure separately, which is a lot of duplication.

[Memphiz]

That might not work. If we do cpack for generating our nsis package - that cmake code will be so specific that it can do only that (creating a nsis installer)". Correct me if i got this wrong...

[bkuhls]

Seeing https://github.com/xbmc/xbmc/pull/10429 I hope
I found the right place to ask a support question related to
https://github.com/xbmc/xbmc/pull/10409#...-244949373

Without having tested PR10429 yet I would like to ask if
stefansaraev is right in saying that cross-compilation is not
supported by the cmake system atm, even when PR10429.

If this is true, what would be necessary to achieve cross-
compilation support as I would like to help getting the
cmake stuff cross-compile friendly.

[ironic_monkey]

cmake cross is in principle easy. you just need to supply a proper toolchain file, jailing the build to the appropriate directories and off you go.
the problem is that there are certain inventions done in the build system to jail it into the depends environment which are not using standard mechanisms, which stefan points out. those needs to be replaced by the standard cmake mechanisms/variables to do such things. i do not have the complete overview what has been done and not here. it's small yet very important glue-type stuff; i.e. small changes, yet lots of thinking

while it's not my decision, i'm fairly certain 10429 won't land before we have a 100% replacement (i am its author and notice my description..). it certainly will not land in v17!

[joshtantine]

Hi guys, i am new to kodi development .

I followed the steps in the wiki to setup windows dev environment in visual studio
http://kodi.wiki/view/HOW-TO_compile_XBM...ource_code

then i switched over to https://github.com/xbmc/xbmc/blob/master...lding-kodi to generate visual studio project files.

It didnt work , i get error , CMAKE_CXX_COMPILER not found , CMAKE_C_COMPILER not found CMAKE_ASM_COMPILER not found.

Can somebody point me to up to date instructions to setup visual studio project for kodi.

[EDIT]: I am so sorry guys i was using the wrong generator , used the correct generator and it worked

[Montellese]

Yesterday I made some changes in Kodi and built it on Windows in VS. At the end I had almost a hundred build errors about unreferenced symbols from the linker. It took me almost an hour to figure out that actually the "xbmc" project had a single compiler error but then the "kodi" project was still trying to link everything together which resulted in all those linker errors because those symbols were never compiled. Could this be fixed so that the "kodi" project isn't built if the "xbmc" project failed to build? Ideally this would be done for every project depending on another project.

[jediry]

Hi all...finally getting back to this, after a season of being too busy to work on Kodi. I see that while I was out, Team Kodi has managed to get Kodi into the Windows Store. Awesome!

make install
----------------
I do have some questions about the direction the CMake build system is going. In particular, a few months back, I tried to build the installer using "cpack", but I quickly discovered that the CMake stuff is not currently set up well for this. In particular, "make install" did not work (at least on Windows), and cpack wants to run "install" in order to produce the directory structure that it will then package up. I spent a while trying to fix "make install", but it felt like I was fighting the way Kodi's CMake stuff is arranged. Is there documentation anywhere describing the high-level design of Kodi's CMake scripts?

It seems to me that supporting "make install" ought to be a goal, for two reasons:
1. It decouples the directory layout of Kodi from the mechanics of producing an installer. This is nice, because it lets most of the logic for deciding "what files go where" be independent of the specific packaging format used, making it simpler to keep the NSIS and Appx installer in sync (and, for that matter, to keep .deb and .rpm in sync). But in addition to that, it also means that...
2. ...as a developer, I can clone the Kodi repo, run "cmake && make install", and end up with a full Kodi directory structure, identical to what the installer will create, but I don't have to actually run the installer (thereby overwriting whatever "stable" version of Kodi I have on my system). And since the "make install"-ed version has the same directory structure, I can run/debug Kodi without having to set a special environment variable to enable Kodi to find all its "pieces".

Do you agree? If so, do you have thoughts on how to evolve the CMake scripts toward this? I'm happy to help, but I don't want to go build this, just to be told "you did it wrong".

[Max_nl]

Without having tested PR10429 yet I would like to ask if
stefansaraev is right in saying that cross-compilation is not
supported by the cmake system atm, even when PR10429.

Yes, still breaks today when using ones own cross-toolchain.
And as such any PR that wants to remove autotools (which does work properly) is a bit premature IMO.


1) When cross-compiling FindPython.cmake expects that libraries called gmp and libintl exists: https://github.com/xbmc/xbmc/blob/Krypto....cmake#L19
Note that if the target system uses glibc, that will have the gettext functions, and a seperate libintl library is unlikely to be present.
And an autotools build does not require gmp, so is that really necessary?

2) There are regex replace functions in the cmake files that fatally error out if the variable they are operating on is empty.

Code:

CMake Error at scripts/rbpi/ArchSetup.cmake:7 (string):
  string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
  command.

Code:

CMake Error at scripts/rbpi/Macros.cmake:34 (string):
  string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
  command.

3)

[100%] Linking CXX executable kodi.bin
/mnt/nfs/kodi/buildroot-2016.11/output/host/usr/lib/gcc/arm-buildroot-linux-gnueabihf/6.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: cannot find -l-lpthread
collect2: error: ld returned 1 exit status
CMakeFiles/kodi.dir/build.make:458: recipe for target 'kodi.bin' failed

Shouldn't have -l in front of the library names here: https://github.com/xbmc/xbmc/blob/Krypto....cmake#L23

4)

[100%] Linking CXX executable kodi.bin
/mnt/nfs/kodi/buildroot-2016.11/output/host/usr/lib/gcc/arm-buildroot-linux-gnueabihf/6.2.0/../../../../arm-buildroot-linux-gnueabihf/bin/ld: build/windowing/egl/windowing_egl.a(EGLNativeTypeRaspberryPI.cpp.o): undefined reference to symbol 'vc_tv_hdmi_get_supported_modes_new'
/mnt/nfs/kodi/buildroot-2016.11/output/host/usr/arm-buildroot-linux-gnueabihf/sysroot/lib/libvchostif.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/kodi.dir/build.make:400: recipe for target 'kodi.bin' failed
make[4]: *** [kodi.bin] Error 1

Specifying -DCORE_SYSTEM_NAME=rbpi does seem to cause Pi specific code to be compiled, but it doesn't seem to add all the necessary libraries for the proprietary method calls that are not part of any standard. Missing a -lvchostif somewhere.

There may be more issues, stopped here.