This allows building against the Python libraries even when the
Python interpreter/executable is missing. The correct extensions
for the binary modules will be guessed, the tests will fail,
and the bytecode for any pure-Python modules will not be
precompiled.
This also allows us to generate a suitable __init__.py for fixing
up PATH and/or __path__ on platforms that need it to properly
import Python extension modules.
This also involves the creation a new include: Python.cmake
This file will contain utility functions for building Python
modules and installing Python packages.
This requires a macro to override find_package,
as the default behavior in CMake is to fall back
from MODULE onto CONFIG.
Note that Bullet is given a specific override
not to look for a CONFIG, since Bullet tends to
use weird paths in its CONFIG script.
This is preferable because imported targets generally include
all of the relevant information specific to the particular
installation of each package, and without needing to hunt down
a bunch of variables to do it.
To do this, package_option() (which is starting to grow in scope
a little beyond just providing the package option, come to think
of it) is given a new IMPORTED_AS option, which tells the package
configuration system to look for one or more imported targets and
link against them instead.
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 should obviate the need for pystub as well.
Note that it's currently a little bit hacky; the source will
have to be moved to make the CMake dependencies work better.
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 fixes some cases where transitive libraries, as nominated
by a component library, were not being absorbed into a metalib,
due to the library actually not being defined yet. This makes the
logic a little more robust, first by explicitly requiring a metalib
definition to come after all component library definitions, and second
to assume a library "linked" to a component library is a non-component
if it isn't defined (yet).
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.
The rationale for this is in a comment at the top of the main
CMakeLists.txt file. It was getting harder to maintain support for a
version this old, and pretty much no current system has CMake <3.
Good riddance.
Also fixes Interrogate's reliance on the INTERFACE_INCLUDE_DIRECTORIES target
property before generation time by using a generator expression to determine
Interrogate's include flags.
Sam Edwards