Age | Commit message (Collapse) | Author | Files | Lines |
|
Currently, the CMakeList.txt completely overwrites the CMAKE_MODULE_PATH
variable.
This is problematic when an upper-layer buildsystem wants to set its own
module path to use custom modules.
For example, Buldroot [0] provides a custom platform description [1] to
fix cross-compilation issue. Overwriting the module path means that this
custom platform description is not found:
System is unknown to cmake, create:
Platform/Buildroot to use this system, please send your config file
to cmake@www.cmake.org so it can be added to cmake
Providing such a custom platform description is what the upstream cmake
devs suggest [2], quoting:
If a toolchain file specifies CMAKE_SYSTEM_NAME such that a custom
`Platform/MySystem.cmake` file is loaded then the latter can set
them [*] as needed for the target platform.
[*] offending settings causing RPATH issues during cross-compilation.
So we need to append to the module path, rather than replace it blindly.
[0] https://buildroot.org/
[1] https://git.buildroot.org/buildroot/tree/support/misc/Buildroot.cmake
[2] http://public.kitware.com/pipermail/cmake/2017-February/065063.html
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
|
|
I'm not aware of people using it, so I believe it's not worth the hassle
as I'm trying to cut maintenance burden down.
|
|
Should fix #505.
|
|
Fixes https://github.com/apitrace/apitrace/issues/346
Fixes https://github.com/apitrace/apitrace/issues/503
|
|
|
|
cmake often picks up libpng from /usr/local which does not not include
i386 architecture.
|
|
|
|
|
|
|
|
It was been effectively required for a while, but CMake was only
warning if requirement not met.
|
|
Based on code from http://create.stephan-brumme.com/crc32/ .
But tables based on http://sourceforge.net/projects/slicing-by-8/ , to
match SSE42 CRC32 instruction.
|
|
Renaming the library to something else is left to another change, as
there's already a trace lib in the wrappers dir.
|
|
|
|
|
|
|
|
Also remove SSP: it was only being used in Debug builds, and it never
found a bug.
|
|
Sample usage:
cmake -DDOC_INSTALL_DIR=doc/apitrace-x.y.z ...
Fixes https://github.com/apitrace/apitrace/issues/411
|
|
It was to be bumped including DirectComposition headers on MinGW, but
it shouldn't have been commited.
Instead introduce a WINDOWS_XP option to build XP binaries with MinGW.
|
|
MSVC 2013 is still supported. But I hope to make MSVC 2015 a
requirement in the near future.
|
|
We don't care about debugging them, and it can make a significant
performance difference.
|
|
From 3a77ebe1.
|
|
QWebView was deprecated in Qt 5.5 and removed in Qt 5.6. QTextBrowser
seems sufficient for our needs and avoids the hassle of making the code
compatible both with QWebView and QWebEngineView.
|
|
This addresses https://github.com/apitrace/apitrace/issues/377 , but
even with complete DirectComposition specs, one will stumble into
attempts to use undocumented IID_ID3D11PartnerDevice interface.
|
|
|
|
|
|
|
|
Using a glob might fail to detect a new script, if there was no
CMakeLists.txt change. However it seems less likely than me forgetting
to manually add the scripts to the CMakeLists.txt.
https://github.com/apitrace/apitrace/issues/416#issuecomment-174886761
|
|
It was enabled by accident.
|
|
I plan to make more use of C++11 features.
There are backports of GCC 4.9 for most Linux distributions, as
documented on https://github.com/apitrace/apitrace/wiki/GCC , so no
point in dealing with the missing C++11 features from ealier GCC C++ /
libstdc++ versions.
|
|
No longer necessary given that for a long time now that GCC hasn't been
included in Xcode.
|
|
|
|
|
|
Now that we force the enablement of SSE2 on Windows there's less things
we need to check.
|
|
I thought that non-SSE2 capable machines were no longer used in
practice, but apparently not.
We assume SSE2 is available on 32 bits Windows, as that's what MSVC
does, but there's no major reason to force using SSE2 on 32 bits x86
Linux builds, so disable it.
Fixes #394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To avoid GCC 4.9 dependency.
Fixes #370.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In preparation for D3D11.3 support.
|
|
Which is the same as requiring GCC 4.7.
|
|
For C++11 non-static data member initializer support.
|