CMake 3.15+ provides the former, which extension modules should link
against in order to ensure the ABI-appropriate linkage for the
platform.
For older versions of CMake, try to hack up the correct linkage for
the platform. If the platform isn't recognized, tell the user to
upgrade CMake.
This also tweaks p3pystub just a bit, since now it's actually relied
upon to resolve runtime link issues when p3dcparse pulls in direct,
as p3dcparse doesn't link against Python at all.
It doesn't contain any source files anymore (see last commit),
so for non-metalib builds, this is necessary for CMake to
understand how to invoke the linker/archiver.
This code is so heavily dependent on Python (and makepanda
doesn't even build it into libp3direct) that we shouldn't
even try to put it in the libp3direct library ourselves.
This makes it so some options can be toggled on a per-configuration
basis (for multi-config generators), as long as they don't affect what
targets are actually being generated.
Create a variable that can be used to tell if a generator is multiconfig or not. Since this variable is only available on CMake 3.9 or higher, we'll try to make an educated guess on a lower CMake version.
This is, sadly, not added until CMake 3.4.
This commit avoids continue() by restructuring the loops so
that the conditions previously being used for continue() are
no longer needed. The alternative would've been to encase the
loop bodies massive ifs, but I find that to be a poor choice
for readability.
This was broken by 2d5bdb351557ed1ee51e4026aac26e251045c2a0,
which wrote -D flags as -D'symbol' -- this choked Windows,
so this commit turns it off in that case.
It's a shame there's no generator expression to escape quotes,
otherwise this hack wouldn't even be needed.
The main change here is it uses an array of expected filenames,
which optionally itself feeds off of a compiler definition, rather
than hardcoding the expected filenames straight into the search
code.
The other change is this code is omitted when building statically.
When cross-compiling, the build directory won't contain
anything useful to the host system. Therefore, we shouldn't
register the build directory in CMake's package registry.
It describes more accurately what it does, which is attach the MouseWatcher to it. Though it was intended to help with GUI navigation, it can also be used for eg. polling button states.
This allows using mutices in with-blocks and wraps up the functionality of acquire() and try_acquire() into a single acquire(blocking=True).
Furthermore, the GIL is no longer released in cases of no contention.
