Funnily enough, this broke building of anything depending on the Audio
library with OpenAL Soft 1.22.2.
It now sets the OPENAL_INCLUDE_DIR variable for backwards compatibility
purposes, but in 1.21.1 and before such variable was not set in
OpenALConfig.cmake at all, thus this expression did nothing. But now
using this variable by accident led to
CMake Error at src/MagnumPlugins/AnyAudioImporter/CMakeLists.txt:46 (target_link_libraries):
Error evaluating generator expression:
$<TARGET_PROPERTY:OpenAL::OpenAL,INTERFACE_INCLUDE_DIRECTORIES>
Target "OpenAL::OpenAL" not found.
which is rather strange -- the OpenAL::OpenAL target (which is a local
alias scoped only to the Magnum/Audio directory from where
find_package(OpenAL) was called) *is* propagated correctly from the
target_link_libraries() call, but at the same time it's not propagated
if it's passed via target_include_directories(). I don't know why (and
probably don't want to know), in any case the expression is not needed
and removing it altogether fixes everything.
Because it somewhat confusingly may have implied that it's really
composed of 8-bit bools, and not bits. The same reasoning was used to
pick the name for Corrade's Containers::BitArray.
Backwards compatibility aliases are in place as usual, however the
internal BoolVectorConverter is now BitVectorConverter and there
unfortunately cannot be any backwards compatibility. This breaks only
GLM and Eigen integration in the magnum-integration repo, which I'm
fixing immediately. I don't expect any user code to use this internal
helper. For regular vectors maybe, for this one definitely not.
This is what commit ca722eac6e should
have been.
Sorry for breaking a non-deprecated MSVC build once again. The reason it
"appeared to work" for me was that on deprecated builds, Manager.h
includes Manager.hpp for backwards compatibility. On non-deprecated it
doesn't and MSVC ends up dying on a linker error. But the problem was
not related to extern templates, the problem was that there was a
compiler-specific ifdef in the cpp file which exported the class for all
compilers but MSVC, somehow. And so when I removed extern template from
the header, it still worked everywhere, except MSVC and except a
non-deprecated build.
Similar to the change done in Corrade, see the commit for details:
878624ac36
Wow, this is probably the most backwards-compatibility code I've ever
written. Can't wait until I can drop all that.
Originally I copied this over from SceneGraph template classes, where it
was used to prevent the compiler from needlessly instantiating a
template that was already available elsewhere. But this is a different
case, the extern template is not preventing any instatiation of
anything, no code is inline, so it apparently should not have been there
at all, instead of being disabled for ḾinGW GCC and clang-cl, and then
subsequently discovering it also breaks MinGW Clang.
Since I'm not testing with MinGW Clang on the CI (only with MinGW GCC),
this went unnoticed for a while -- sorry.
While branching on a compiler is rather common, checking a particular
compiler version should be needed only rarely. Thus minimize use of such
macros to make them easier to grep for.
It's more useful if the Error class is directly referenced than saying
just "error output" -- so people can grab it, redirect it, etc. Also
drop the useless "does what it is expected to do on success" sentences
that add no value whatsoever.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
I wanted to avoid including extra stuff with the Manager.hpp split, but
this would make it even worse than having Array and String included
unconditionally. Fortunately it's enough to simply not even have the
declaration.
Probably a leftover from when these dependencies were handled in a
much shittier way? For as long as I remember, enabling WITH_GL_INFO
always enabled WITH_GL and WITH_WINDOWLESSWHATEVERAPPLICATION
implicitly.
This makes it much less annoying to pass arbitrarily typed data, such as
std::uint8_t or char8_t and what not. It was already done like this for
the new shader converter plugins, where the input is often 32-bit ints
for SPIR-V.
OTOH the internal virtual API is kept with ArrayView<const char>, as
that makes it easier to operate on by the implementations.
Disabling engine startup log or modifying enabled extensions /
workarounds from the application side was one of the common pain
points and this should *finally* solve the problem. This Configuration
is now inherited by the usual Platform::*Application::GLConfiguration /
Platform::Windowless*Application::Configuration classes people are used
to, so for the end user it's just as if these classes got a bunch new
options.
Having this, I also extended the ContextGLTest to verify that the
Configuration and command-line options do what's expected because that
hadn't automated tests until now. The test is mostly a copy of what I
did for Vulkan already, nothing special. Additionally all
Platform*ApplicationTest executables gained a new --quiet option to
verify that the GL::Context::Configuration subset gets correctly passed
from the Application code, because that's something we can't really
verify in an automated way.
An unqualified link to Extensions.h will, guess what -- pick the last
Extension.h header that Doxygen came across. So in this case
Magnum/Vk/Extensions.h. With no warning or any other hint that something
MAYBE could be wrong. FFS.
Because the cost of hundreds of tiny allocations when filling a
std::unordered_map (and then the cache unfriendliness of the whole
thing) definitely overweights the potential speedup by searching in O(1)
instead of O(log n). Same approach is chosen in the upcoming Vulkan
wrapper, I just backported it here.
This strips about 8 kB off the Emscripten build.
Otherwise, in case of SDL and GLFW, where we don't really know the DLL
name, it would create a file named `bin` instead of copying into a newly
created bin/ directory if it doesn't exist yet. That happens in case of
a static build, where there are no DLLs and thus
CMAKE_RUNTIME_OUTPUT_DIRECTORY gets never created.
Same as in Corrade. Because BUILD_STATIC is independent between Corrade
and Magnum this option is also independent -- the corner cases and bad
interactions would be otherwise too complex to handle (e.g., in case of
a dynamic Corrade and static Magnum it would be impossible to enable
this option for Magnum etc etc).
Vladimír Vondruš