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 2d5bdb3515,
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.
This changes the structure to use paths like `build/Release/lib`
instead of `build/lib/Release`, so that the `build/Release` directory
more closely mimics the structure of `build` when in single-configuration
mode.
This is for better cross-compilation friendliness, so the pzip
binary used during the build doesn't have to be the same as the
pzip binary produced during the build.
This allows exporting (a stub function that forwards to) a
function that returns a value - it's particularly useful in
the graphics plugins for the "get_pipe_type_foo()" functions.
This also frees up CMake from needing to use any of the source
files in the metalibs/*/ directories.
For now, p3vision is only built if either OpenCV or
ARToolKit is available. It does contain some generic
webcam access code, so it might be worth building it
when that's available.
I inadvertently rewrote FindVRPN.cmake doing this - I didn't
think to check if it already existed before overwriting.
Oh well, the new version is a bit simpler.
That is, they should appear under the build directory of the
component library they're Interrogating; this is just an
organizational change to keep the cmake/panda/ directory from
accumulating Interrogate clutter.
This uses generator expressions to make sure the definitions are
discovered transitively. The output _igate.cxx file also has its
definitions applied to it via a source file property rather than
via add_definitions(), which prevents them from leaking to other
targets.
Previously, we would override target_link_libraries() to support
object "linking" since this wasn't supported in versions of CMake
before 3.12. Now that 3.12 is released, we only do it for versions
of CMake before that release.
By "flatten" I mean that component libraries aren't referenced by
genex anymore; instead, their include directories and libraries
are copied out of their interfaces and into the interface of
the metalib.
This prepares for exporting our targets, by making sure that the
component libraries don't have to be installed for CMake to be
able to export metalibs.
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.
Sam Edwards
Donny Lawrence