We are already using target_link_options, and while it's possible to keep supporting older versions, it doesn't sound worth it. I can revert this out if someone gives me a really good reason to.
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.
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.
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.
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).