TL;DR:
5eee8ca6 Compatibility with older versions of cmake.
Repository: https://git.tartarus.org/simon/putty.git
On the web: https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer: Simon Tatham <anakin at pobox.com>
Date: 2021-10-29 18:10:41
commit 5eee8ca648c8453ff5308f7a009277eccfa80d16
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=5eee8ca648c8453ff5308f7a009277eccfa80d16;hp=e24444dba81ef960b02bd7aa666ca5c6d46f03eb
Author: Simon Tatham <anakin at pobox.com>
Date: Fri Oct 29 18:08:18 2021 +0100
Compatibility with older versions of cmake.
After this change, the cmake setup now works even on Debian stretch
(oldoldstable), which runs cmake 3.7.
In order to support a version that early I had to:
- write a fallback implementation of 'add_compile_definitions' for
older cmakes, which is easy, because add_compile_definitions(FOO)
is basically just add_compile_options(-DFOO)
- stop using list(TRANSFORM) and string(JOIN), of which I had one
case each, and they were easily replaced with simple foreach loops
- stop putting OBJECT libraries in the target_link_libraries command
for executable targets, in favour of adding $<TARGET_OBJECTS:foo>
to the main sources list for the same target. That matches what I
do with library targets, so it's probably more sensible anyway.
I tried going back by another Debian release and getting this cmake
setup to work on jessie, but that runs CMake 3.0.1, and in _that_
version of cmake the target_sources command is missing, and I didn't
find any alternative way to add extra sources to a target after having
first declared it. Reorganising to cope with _that_ omission would be
too much upheaval without a very good reason.
CHECKLST.txt | 3 +++
CMakeLists.txt | 2 +-
cmake/setup.cmake | 14 ++++++++++++--
crypto/CMakeLists.txt | 4 +++-
doc/CMakeLists.txt | 2 +-
unix/CMakeLists.txt | 12 ++++++------
6 files changed, 26 insertions(+), 11 deletions(-)