Except Graphviz's `dot` Doxygen may use few other utilities like
`mscgen` (Message Sequence Chart) and `dia` (Diagram Editor).
Now this module allows to manage Doxygen settings from `CMakeLists.txt`
and forget about `Doxyfile`s. Also it provides a helper function
to add a target to generate documentation: `doxygen_add_docs`.
Implement code review notes:
- Introduce `COMPONENTS` to find: `dot`, `mscgen` and `dia`;
- Deprecate variables `DOXYGEN_SKIP_DOT`, `DOXYGEN_EXECUTABLE`,
`DOXYGEN_DOT_EXECUTABLE`, `DOXYGEN_DOT_FOUND` in favour of
`doxygen_add_docs ` usage instead;
- Properly handle paths to found tools in Windows;
- Prevent adding a custom target if Doxygen was not really found;
- Introduce exported (executable) targets for found components.
Co-Author: Craig Scott <craig.scott@crascit.com>
Cygwin's installation directory is mainly needed to use some programs
of it, irrespectively of the target architecture. However, find_path
does not consider cygwin with architecture different than the target
architecture. This is because cygwin's installation path is retrieved
from the registry. WOW64 view is not used by find_path if generating
for 32-bit architecture and vice versa, so cygwin is not found then.
find_program tries both views, this way a 64-bit cygwin may be used
for 32 bit build and vice versa.
Use `cmake_host_system_information` to query the VS Installer tool for
the locations of VS versions since VS 2017 does not provide registry
entries anymore. Add a loop to simplify addition of future versions.
Remove highly specialized and totally positional argument handling in
find_dependency macro, and instead just pass arguments through to
find_package. This gives users access to the full suite of arguments
that find_package knows, and is backward compatible with the old
arguments.
Also, rewrite the unit tests for this, since the old tests are
exclusively focused on testing the old argument handling and are no
longer applicable, and add some success tests (the old tests did not
even set up the CMake state in a way that CMake had any hope of ever
finding the test package).
Rename our recently added imported targets to match those provided by
the upstream's CMake-based build. That way a project using
`find_package(Protobuf)` can get the same target names no matter how
protobuf is found.
Suggested-by: Konstantin Podsvirov <konstantin@podsvirov.pro>
PGI on Windows should use the Visual C++ linker and librarian and not
the ar provided for legacy reasons. The compiler parameters themselves
are the same as their Linux parameters and not compatible to MSVC
however.
PGI demands -Bdynamic (/MD equivalent) for linking together dynamic
libraries, so we should make it our default mirroring the settings of
e.g. Visual C++ and Intel C++.
Since PGI does not write linker directives into objects, the necessary
libraries have to be parsed from commandline. PGI does however link the
Visual C++ runtime libraries, so they have to be filtered out to ensure
no collision with settings of other languages can occur.
Update the module to account for commit v3.4.0-rc1~342^2 (Factor an
<INCLUDES> placeholder out of <FLAGS> in rule variables, 2015-07-13)
and v2.6.0~537 (Create COMPILE_DEFINITIONS property for targets and
source files, 2008-01-14).
Fixes: #16904
Now has keyword-based arguments (old syntax form is still supported).
Discovered tests can have a prefix and/or suffix added to the test names
and the list of discovered tests is available to the caller. The working
dir can also be set and the dependency on the source files is now
optional instead of mandatory.
Since commit v3.8.0-rc1~132^2 (FindOpenSSL: Check that both CRYPTO and
SSL libraries are present, 2017-01-03) we require both crypto and ssl
libraries to be present. This makes sense because `OPENSSL_LIBRARIES`
lists both and breaks when one is not found. However, prior to that
fix we supported finding only the crypto library and using it through
the imported target. Drop the requirement for ssl to restore support
for using crypto alone.
Later this module should be taught to support the `COMPONENTS` argument
of `find_package`.
Fixes: #16882
The fix in commit v3.8.0-rc1~257^2~1 (FindDevIL: fail properly when
library is not found, 2016-11-24) removed the previously-provided
`IL_FOUND` result variable. Set it for compatibility and update the
documentation to mention the new variable.
Fixes: #16881
Each missing variable is added to the string as " ${var}" which causes
the string to always have a leading space. Remove the duplicate space
due to this in the output.
Changes:
- DISPLAY_NAME and DESCRIPTION in CPackIFW module now is MULTI_ARGS;
- Added internationalization support for DisplayName and Description
properties in cmCPackIFWPackage class;
- Added documentation to CPackIFW module;
- Added release note.
During search of the library file `pkg_check_modules()` attempts to find
it in last specified library path in `${_prefix}_LDFLAGS`, that after
dependency resolving contains path to standard location.
So in case when `${_prefix}_LDFLAGS` has:
-L/prefix;-L/usr/local/lib;-llibrary_from_prefix;-ldependency
`library_from_prefix` will not be found.
As solution need try to find the library in all paths preceding to the
library.
Fixes: #16873
I encountered an issue where not all prerequisites would be listed by
`get_prerequisites` since some of the prerequisites cannot be resolved
and are added to the list of unseen prerequisites. This has the side
effect of clearing the list of `prerequisites_var` and thus removes some
prerequisites from the list. Fix it.
