Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cmake] Small improvements and fixes #10078

merged 5 commits into from Jul 7, 2016


Copy link

commented Jul 6, 2016

See commit messages for details.

@laurimyllari, @FernetMenta for the build fix 0789567. This ensures that ColorManager can be built on Windows, but also for Linux I think it's better not to rely on non-standard techniques. Would be great if you could test if I didn't break anything, I've just compile tested it here.

@Fneufneu: 48993cc fixes the in-source builds, as discussed in cc735b7#commitcomment-18124684

For the rest, maybe @hudokkow want's to have a quick look :)

[cmake] Print CMake version and add some warnings
CMake 3.5.1 suffers from a crash at configure time that happens on some
This is fixed in 3.5.2.

Darwin requires CMake at least 3.4 or the usage of the patched version
in depends.

# Get all propreties that cmake supports and convert them to a list.

This comment has been minimized.

Copy link

hudokkow Jul 6, 2016


Rest looks fine. I had to pick on something, 😜


This comment has been minimized.

Copy link

commented Jul 7, 2016

@fetzerch thanks! Sorry, I did not notice the non-standard on review.

fetzerch added 4 commits Jul 3, 2016
[ColorManager] Replace non-standard VLA with vector
Variable-length arrays are not part of C++ and only allowed in C99. While
they are supported as a GCC extension (if -pedantic is not set), they
cannot be used with MSVC.

This commit replaces the VLA in ColorManager by a std::vector.
[cmake] Opt out if platform configuration cannot be found
For example on Darwin platforms this can indicate a missing toolchain
[cmake] Fix export-files when building in-source
In-source builds were broken due to a mistake in the export-files
logic. Even though this commit resolves the problem, it is recommended
building out-of-source.

@fetzerch fetzerch force-pushed the fetzerch:cmake_fixes_warnings branch from 48993cc to bfb7355 Jul 7, 2016


This comment has been minimized.

Copy link
Member Author

commented Jul 7, 2016

@hudokkow: Fixed 2 typos, thanks.

fetzerch referenced this pull request Jul 7, 2016
[cmake] Speed up export-files target
The export-files target mirrors files from the source tree to the build
tree (such as system/ userdata/ addons/) by doing a byte wise diff
which is slow. Instead generate a CMake script that uses file(COPY)
which only copies if the source is newer.

Measurements on Linux machine (real time, cmake + make export-files):
- first run (with cleaned page caches):       19+27s vs. 19+6s
- consecutive run (with cleaned page caches): 12+35s vs. 12+3s
- consecutive run:                             6+18s vs.  6+0.3s

Measurements on Windows machine (real time, cmake + make export-files):
- first run:                                  43+65s vs. 52+8s
- consecutive run:                            19+62s vs. 29+1.5s

This comment has been minimized.

Copy link
Member Author

commented Jul 7, 2016

jenkins build and merge

@jenkins4kodi jenkins4kodi merged commit 7fe773f into xbmc:master Jul 7, 2016

1 of 4 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
default I've found some spare time so building this now
Details Yeah yeah I'll get to it when i have some time
continuous-integration/appveyor/pr AppVeyor build succeeded

@fetzerch fetzerch deleted the fetzerch:cmake_fixes_warnings branch Jul 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
4 participants
You can’t perform that action at this time.