If Magnum and Corrade get installed into the same directory,
target_include_directories() or target_link_libraries() with Corrade
before Magnum will result in the (usually stale) installed Magnum
headers being picked over the local ones. Which is unwanted, so try to
always put the local Magnum include path first.
Tested manually by installing to an arbitrary location and editing
configure.h to contain an #error. That failed for the Text library, and
with these changes it now doesn't fail anymore, but that's not a
guarantee that I managed to fix all such cases.
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
Could make sense to eventually turn those into --magnum-whatever options
and have them available always. There's however the yet-unanswered
question of how to provide help for those if a GL/Vk context has its own
set of options, and how to make them not warn about mutually invalid
options.
This means I (and people making their own plugins) don't need to go and
update each and every plugin once the version in the interface string
gets bumped after a (silent) ABI break. Such as when new virtual
functions get added, as those often lead to strange crashes if the
plugins don't get rebuilt after.
The plugins will now use this macro, which means they'll
automatically embed an interface string that was present in the base
class header at build time. However, when the base class updates, the
previous string is still embedded in the plugin binary, which will then
fail to load -- this being automatic doesn't mean the original purpose
is lost. Subsequently rebuilding the plugins from source will make them
pick up the updated interface string again.
Of course I used the wrong `CORRADE_FAIL_IF(false, ...)` in a few
places. Yet another confirmation it was too hard to use and a dedicated
macro is needed.
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.
Vladimír Vondruš