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
merged 5 commits into from
Jul 7, 2016

Conversation

fetzerch
Copy link
Member

@fetzerch fetzerch commented Jul 6, 2016

See commit messages for details.

Pings:
@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 3.5.1 suffers from a crash at configure time that happens on some
Systems: http://cmake.org/Bug/view.php?id=16044
This is fixed in 3.5.2.

Darwin requires CMake at least 3.4 or the usage of the patched version
in depends.
@fetzerch fetzerch added Type: Fix non-breaking change which fixes an issue Type: Improvement non-breaking change which improves existing functionality v17 Krypton CMake labels Jul 6, 2016
@fetzerch fetzerch added this to the Krypton 17.0-alpha3 milestone Jul 6, 2016
endforeach()
endmacro()

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

This comment was marked as spam.

@FernetMenta
Copy link
Contributor

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

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.
For example on Darwin platforms this can indicate a missing toolchain
file.
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
Copy link
Member Author

fetzerch commented Jul 7, 2016

@hudokkow: Fixed 2 typos, thanks.

fetzerch referenced this pull request Jul 7, 2016
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
@fetzerch
Copy link
Member Author

fetzerch commented Jul 7, 2016

jenkins build and merge

@jenkins4kodi jenkins4kodi merged commit 7fe773f into xbmc:master Jul 7, 2016
@fetzerch fetzerch deleted the cmake_fixes_warnings branch July 7, 2016 17:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CMake Type: Fix non-breaking change which fixes an issue Type: Improvement non-breaking change which improves existing functionality v17 Krypton
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants