This also involves the creation a new include: Python.cmake
This file will contain utility functions for building Python
modules and installing Python packages.
Instead, let's use a PKG::PKGNAME interface library, which simplifies
the linking and also allows us to use imported libraries from
find_package in the future.
This enables the "setters" to behave in a way that people expect setters to behave. Since `setText(None)` now does not behave expectedly, a `clearText()` has also been added to remove the text.
Closes#385
These methods are supposed to override the underlying C methods, which do have underscore aliases, so it is important that the Python class defines these underscore aliases as well.
They export no code, and are really only used to contain several
preprocessor macros relevant to their respective packages. On
Windows, they're a problem: MSVC doesn't generate a .lib when
compiling a .dll that exports nothing.
This allows using a coroutine to build up a more complex sequence including transitions (eg. scripted cutscene), as well as provide a standard way to register callbacks upon completion of the transition.
These were removed by 88dbb31daa under the assumption that they were not used, but it has recently come to my attention that there is still code out there that uses these.
PriorityCallbacks has been updated to be compatible with Python 3 by only comparing the priority, rather than the (priority, callback) tuple. This also has the side-effect of ditching the bisect dependency.
Also moves testing code from the source to the unit tests.
Instead of wrapping the whole subdirectory's CMakeLists in
a gigantic if block, we use if(NOT HAVE_FOO) + return()
This is tidier since it keeps the indentation generally consistent
across all CMakeLists files.
This commit isn't technically quite right, since Interrogate should
use the definitions from COMPILE_DEFINITIONS but the module should
be built with INTERFACE_COMPILE_DEFINITIONS, but whatever. That can
be changed if it becomes a nuisance later on.
The rationale here is it's consistent with how CMake treats these
two properties.
This changes the target_link_libraries() declarations so they only
go directly to a component library if it's in the same metalib.
If it's outside of the metalib, the correct thing to do is link against
the metalib. CMake takes care of the transitive linking for us, so
there isn't actually any big change here.
Sam Edwards
rdb
jspam
bfrisby2000
Psychotropos