Since commit v3.7.0-rc1~142^2~1 (VS: Explicitly default to v100 toolset
in Visual Studio 2010, 2016-07-21) we prefer to always set a platform
toolset explicitly so that `CMAKE_VS_PLATFORM_TOOLSET` can be reported.
However, the `v100` default for the VS 10 generator is not appropriate
for all environments. We fixed support for VS 2010 Express Edition in
commit v3.7.0-rc1~142^2 (VS: Do not default to missing v100 64-bit
toolset on VS 2010 Express, 2016-09-09).
Fix support for the standalone Windows7.1SDK toolset environment by
recognizing the `PlatformToolset` environment variable that it sets to
`Windows7.1SDK` and using this as our default toolset instead.
Closes: #16483
The documentation of this option [1] claims that the default is off, but
VS seems to use `-Zc:inline` by default if `RemoveUnreferencedCodeData`
does not appear in the `.vcxproj` file. Add the flag table entry to
allow use of the flag to be configured.
[1] https://msdn.microsoft.com/en-us/library/dn642448.aspx
Suggested-by: Serti Ayoub <ayb.serti@gmail.com>
The negative form of the `-Zc:inline` flag is missing from
c:/Program Files (x86)/Microsoft Visual Studio/2017/Professional/Common7/IDE/VC/VCTargets/1033/cl.xml
so it was not included in our flag table automatically. Add it manually.
Suggested-by: Serti Ayoub <ayb.serti@gmail.com>
OpenSSL 1.1 made some CTX structures opaque. Port our code to use the
structures only through pointers via OpenSSL 1.1 APIs. Use our adaption
layer to make this work with OpenSSL 1.0 and below.
Patch-by: Tomas Mraz <tmraz@redhat.com>
Patch-from: https://bugzilla.redhat.com/1383744
Add private forwarding headers for `openssl/{evp,hmac}.h` to give us a
central place to add adaptation code to work across multiple
incompatible OpenSSL versions. Provide compatibility implementations of
some OpenSSL 1.1 APIs when using older OpenSSL versions.
Revert commit v3.7.0-rc1~266^2 (Xcode: Obey SYSTEM keyword for includes,
2015-08-31). It worked for C, C++, and Swift but not for GNU Assembly
files for which Xcode has no property to set flags.
Closes: #16449
Expose the binutils' machine name (typically used as a prefix on the
tool names) publicly. This is expected to match the `gcc -dumpmachine`
value.
Suggested-by: Ruslan Baratov <ruslan_baratov@yahoo.com>
The NDK provides prebuilt toolchain files in directories named for the
host architecture. The NDK build system calls this `HOST_TAG`.
Expose the value publicly for use by clients that need to pass it
to external tools.
Suggested-by: Ruslan Baratov <ruslan_baratov@yahoo.com>
When this variable is not set by the user or toolchain file, set it to
the default selected. This will be useful for client code that needs to
pass the value to an external tool that needs to find the same toolchain
in the NDK. Leave it empty for a standalone toolchain.
Suggested-by: Ruslan Baratov <ruslan_baratov@yahoo.com>
Since commit v3.7.0-rc1~348^2~3 (FindBISON: Change usage of [VERBOSE
<file>] to [VERBOSE [<file>]], 2016-07-16) we always list the VERBOSE
output file as an output of our custom command even if the option is not
used. This causes the rule to re-run every time (e.g. with Ninja).
Revert one hunk from that change (that looks incorrect) to fix it.
Closes: #16426
Refactoring in commit v3.6.0-rc1~134^2~10 (Autogen: Split out moc file
generation code to dedicated method, 2016-04-18) removed the
unconditional creation of the `<target>_automoc.cpp` file. Now it is
generated only when `AUTOMOC` is enabled. However, if this file is not
created then our internal `GenerateAll` setting is enabled on every
build, causing `AUTORCC` to re-generate its file(s) every time. Fix the
`GenerateAll` setting to be used only for when autogen settings change.
The old logic was left from when we had only automoc.
Closes: #16413
The options to the find_library call to create the imported target
used a literal string "HINTS /path NO_DEFAULT_PATH" instead of a
list of options. This resulted in never finding any library in my
testing.
Refactoring in commit v3.6.0-rc1~72^2 (HDF5: Rework component searching
to correctly find HL for all bindings, 2016-05-12) changed the default
behavior from finding only the C bindings to finding everything for the
enabled languages. Restore the original behavior for compatibility and
because many projects need only the C bindings.
Closes: #16397
Running CMake on it caused the following error:
error: Target "publisher" links to target "Qt5::DBus" but the target
was not found. Perhaps a find_package() call is missing for an
IMPORTED target, or an ALIAS target is missing?
Add the missing DBus component.