nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
395c228bee
putty-source/CMakeLists.txt

155 lines
3.6 KiB
CMake
Raw Normal View History

Replace mkfiles.pl with a CMake build system. This brings various concrete advantages over the previous system: - consistent support for out-of-tree builds on all platforms - more thorough support for Visual Studio IDE project files - support for Ninja-based builds, which is particularly useful on Windows where the alternative nmake has no parallel option - a really simple set of build instructions that work the same way on all the major platforms (look how much shorter README is!) - better decoupling of the project configuration from the toolchain configuration, so that my Windows cross-building doesn't need (much) special treatment in CMakeLists.txt - configure-time tests on Windows as well as Linux, so that a lot of ad-hoc #ifdefs second-guessing a particular feature's presence from the compiler version can now be replaced by tests of the feature itself Also some longer-term software-engineering advantages: - other people have actually heard of CMake, so they'll be able to produce patches to the new build setup more easily - unlike the old mkfiles.pl, CMake is not my personal problem to maintain - most importantly, mkfiles.pl was just a horrible pile of unmaintainable cruft, which even I found it painful to make changes to or to use, and desperately needed throwing in the bin. I've already thrown away all the variants of it I had in other projects of mine, and was only delaying this one so we could make the 0.75 release branch first. This change comes with a noticeable build-level restructuring. The previous Recipe worked by compiling every object file exactly once, and then making each executable by linking a precisely specified subset of the same object files. But in CMake, that's not the natural way to work - if you write the obvious command that puts the same source file into two executable targets, CMake generates a makefile that compiles it once per target. That can be an advantage, because it gives you the freedom to compile it differently in each case (e.g. with a #define telling it which program it's part of). But in a project that has many executable targets and had carefully contrived to _never_ need to build any module more than once, all it does is bloat the build time pointlessly! To avoid slowing down the build by a large factor, I've put most of the modules of the code base into a collection of static libraries organised vaguely thematically (SSH, other backends, crypto, network, ...). That means all those modules can still be compiled just once each, because once each library is built it's reused unchanged for all the executable targets. One upside of this library-based structure is that now I don't have to manually specify exactly which objects go into which programs any more - it's enough to specify which libraries are needed, and the linker will figure out the fine detail automatically. So there's less maintenance to do in CMakeLists.txt when the source code changes. But that reorganisation also adds fragility, because of the trad Unix linker semantics of walking along the library list once each, so that cyclic references between your libraries will provoke link errors. The current setup builds successfully, but I suspect it only just manages it. (In particular, I've found that MinGW is the most finicky on this score of the Windows compilers I've tried building with. So I've included a MinGW test build in the new-look Buildscr, because otherwise I think there'd be a significant risk of introducing MinGW-only build failures due to library search order, which wasn't a risk in the previous library-free build organisation.) In the longer term I hope to be able to reduce the risk of that, via gradual reorganisation (in particular, breaking up too-monolithic modules, to reduce the risk of knock-on references when you included a module for function A and it also contains function B with an unsatisfied dependency you didn't really need). Ideally I want to reach a state in which the libraries all have sensibly described purposes, a clearly documented (partial) order in which they're permitted to depend on each other, and a specification of what stubs you have to put where if you're leaving one of them out (e.g. nocrypto) and what callbacks you have to define in your non-library objects to satisfy dependencies from things low in the stack (e.g. out_of_memory()). One thing that's gone completely missing in this migration, unfortunately, is the unfinished MacOS port linked against Quartz GTK. That's because it turned out that I can't currently build it myself, on my own Mac: my previous installation of GTK had bit-rotted as a side effect of an Xcode upgrade, and I haven't yet been able to persuade jhbuild to make me a new one. So I can't even build the MacOS port with the _old_ makefiles, and hence, I have no way of checking that the new ones also work. I hope to bring that port back to life at some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
cmake_minimum_required(VERSION 3.12)
project(putty LANGUAGES C)
include(cmake/setup.cmake)
add_library(utils STATIC
New library-style 'utils' subdirectories. Now that the new CMake build system is encouraging us to lay out the code like a set of libraries, it seems like a good idea to make them look more _like_ libraries, by putting things into separate modules as far as possible. This fixes several previous annoyances in which you had to link against some object in order to get a function you needed, but that object also contained other functions you didn't need which included link-time symbol references you didn't want to have to deal with. The usual offender was subsidiary supporting programs including misc.c for some innocuous function and then finding they had to deal with the requirements of buildinfo(). This big reorganisation introduces three new subdirectories called 'utils', one at the top level and one in each platform subdir. In each case, the directory contains basically the same files that were previously placed in the 'utils' build-time library, except that the ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c, winmisc.c, winmiscs.c, winutils.c) have been split up into much smaller pieces.
2021-04-17 14:22:20 +00:00
utils/base64_decode_atom.c
utils/base64_encode_atom.c
utils/bufchain.c
utils/buildinfo.c
utils/burnstr.c
utils/chomp.c
utils/conf.c
utils/conf_dest.c
utils/conf_launchable.c
utils/ctrlparse.c
utils/debug.c
utils/dupcat.c
utils/dupprintf.c
utils/dupstr.c
utils/encode_utf8.c
utils/fgetline.c
utils/host_strchr.c
utils/host_strchr_internal.c
utils/host_strcspn.c
utils/host_strduptrim.c
utils/host_strrchr.c
utils/marshal.c
utils/memory.c
utils/memxor.c
utils/miscucs.c
utils/null_lp.c
utils/nullseat.c
utils/nullstrcmp.c
utils/out_of_memory.c
utils/parse_blocksize.c
utils/prompts.c
utils/ptrlen.c
utils/read_file_into.c
utils/seat_connection_fatal.c
utils/sessprep.c
utils/sk_free_peer_info.c
Adopt a new universal implementation of smemclr(). This new implementation uses the same optimisation-barrier technique that I used in various places in testsc: have a no-op function, and a volatile function pointer pointing at it, and then call through the function pointer, so that nothing actually happens (apart from the physical call and return) but the compiler has to assume that _anything_ might have happened. Doing this just after a memset enforces that the compiler can't have thrown away the memset, because the called function might (for example) check that all the memory really is zero and abort if not. I've been turning this over in my mind ever since coming up with the technique for testsc. I think it's far more robust than the previous smemclr technique: so much so that I'm switching to using it _everywhere_, and no longer using platform alternatives like Windows's SecureZeroMemory().
2021-04-17 16:59:43 +00:00
utils/smemclr.c
New library-style 'utils' subdirectories. Now that the new CMake build system is encouraging us to lay out the code like a set of libraries, it seems like a good idea to make them look more _like_ libraries, by putting things into separate modules as far as possible. This fixes several previous annoyances in which you had to link against some object in order to get a function you needed, but that object also contained other functions you didn't need which included link-time symbol references you didn't want to have to deal with. The usual offender was subsidiary supporting programs including misc.c for some innocuous function and then finding they had to deal with the requirements of buildinfo(). This big reorganisation introduces three new subdirectories called 'utils', one at the top level and one in each platform subdir. In each case, the directory contains basically the same files that were previously placed in the 'utils' build-time library, except that the ones that were extremely miscellaneous (misc.c, utils.c, uxmisc.c, winmisc.c, winmiscs.c, winutils.c) have been split up into much smaller pieces.
2021-04-17 14:22:20 +00:00
utils/smemeq.c
utils/ssh2_pick_fingerprint.c
utils/sshutils.c
utils/strbuf.c
utils/string_length_for_printf.c
utils/stripctrl.c
utils/tree234.c
utils/validate_manual_hostkey.c
utils/version.c
utils/wcwidth.c
utils/wildcard.c
utils/write_c_string_literal.c
Break up x11fwd.c. This is a module that I'd noticed in the past was too monolithic. There's a big pile of stub functions in uxpgnt.c that only have to be there because the implementation of true X11 _forwarding_ (i.e. actually managing a channel within an SSH connection), which Pageant doesn't need, was in the same module as more general X11-related utility functions which Pageant does need. So I've broken up this awkward monolith. Now x11fwd.c contains only the code that really does all go together for dealing with SSH X forwarding: the management of an X forwarding channel (including the vtables to make it behave as Channel at the SSH end and a Plug at the end that connects to the local X server), and the management of authorisation for those channels, including maintaining a tree234 of possible auth values and verifying the one we received. Most of the functions removed from this file have moved into the utils subdir, and also into the utils library (i.e. further down the link order), because they were basically just string and data processing. One exception is x11_setup_display, which parses a display string and returns a struct telling you everything about how to connect to it. That talks to the networking code (it does name lookups and makes a SockAddr), so it has to live in the network library rather than utils, and therefore it's not in the utils subdirectory either. The other exception is x11_get_screen_number, which it turned out nothing called at all! Apparently the job it used to do is now done as part of x11_setup_display. So I've just removed it completely.
2021-04-17 16:01:08 +00:00
utils/x11authfile.c
utils/x11authnames.c
utils/x11_dehexify.c
utils/x11_identify_auth_proto.c
utils/x11_make_greeting.c
utils/x11_parse_ip.c
Replace mkfiles.pl with a CMake build system. This brings various concrete advantages over the previous system: - consistent support for out-of-tree builds on all platforms - more thorough support for Visual Studio IDE project files - support for Ninja-based builds, which is particularly useful on Windows where the alternative nmake has no parallel option - a really simple set of build instructions that work the same way on all the major platforms (look how much shorter README is!) - better decoupling of the project configuration from the toolchain configuration, so that my Windows cross-building doesn't need (much) special treatment in CMakeLists.txt - configure-time tests on Windows as well as Linux, so that a lot of ad-hoc #ifdefs second-guessing a particular feature's presence from the compiler version can now be replaced by tests of the feature itself Also some longer-term software-engineering advantages: - other people have actually heard of CMake, so they'll be able to produce patches to the new build setup more easily - unlike the old mkfiles.pl, CMake is not my personal problem to maintain - most importantly, mkfiles.pl was just a horrible pile of unmaintainable cruft, which even I found it painful to make changes to or to use, and desperately needed throwing in the bin. I've already thrown away all the variants of it I had in other projects of mine, and was only delaying this one so we could make the 0.75 release branch first. This change comes with a noticeable build-level restructuring. The previous Recipe worked by compiling every object file exactly once, and then making each executable by linking a precisely specified subset of the same object files. But in CMake, that's not the natural way to work - if you write the obvious command that puts the same source file into two executable targets, CMake generates a makefile that compiles it once per target. That can be an advantage, because it gives you the freedom to compile it differently in each case (e.g. with a #define telling it which program it's part of). But in a project that has many executable targets and had carefully contrived to _never_ need to build any module more than once, all it does is bloat the build time pointlessly! To avoid slowing down the build by a large factor, I've put most of the modules of the code base into a collection of static libraries organised vaguely thematically (SSH, other backends, crypto, network, ...). That means all those modules can still be compiled just once each, because once each library is built it's reused unchanged for all the executable targets. One upside of this library-based structure is that now I don't have to manually specify exactly which objects go into which programs any more - it's enough to specify which libraries are needed, and the linker will figure out the fine detail automatically. So there's less maintenance to do in CMakeLists.txt when the source code changes. But that reorganisation also adds fragility, because of the trad Unix linker semantics of walking along the library list once each, so that cyclic references between your libraries will provoke link errors. The current setup builds successfully, but I suspect it only just manages it. (In particular, I've found that MinGW is the most finicky on this score of the Windows compilers I've tried building with. So I've included a MinGW test build in the new-look Buildscr, because otherwise I think there'd be a significant risk of introducing MinGW-only build failures due to library search order, which wasn't a risk in the previous library-free build organisation.) In the longer term I hope to be able to reduce the risk of that, via gradual reorganisation (in particular, breaking up too-monolithic modules, to reduce the risk of knock-on references when you included a module for function A and it also contains function B with an unsatisfied dependency you didn't really need). Ideally I want to reach a state in which the libraries all have sensibly described purposes, a clearly documented (partial) order in which they're permitted to depend on each other, and a specification of what stubs you have to put where if you're leaving one of them out (e.g. nocrypto) and what callbacks you have to define in your non-library objects to satisfy dependencies from things low in the stack (e.g. out_of_memory()). One thing that's gone completely missing in this migration, unfortunately, is the unfinished MacOS port linked against Quartz GTK. That's because it turned out that I can't currently build it myself, on my own Mac: my previous installation of GTK had bit-rotted as a side effect of an Xcode upgrade, and I haven't yet been able to persuade jhbuild to make me a new one. So I can't even build the MacOS port with the _old_ makefiles, and hence, I have no way of checking that the new ones also work. I hope to bring that port back to life at some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
${GENERATED_COMMIT_C})
add_library(logging OBJECT
logging.c)
add_library(eventloop STATIC
callback.c timing.c)
add_library(console STATIC
clicons.c console.c)
add_library(settings STATIC
cmdline.c settings.c)
add_library(crypto STATIC
sshaes.c sshauxcrypt.c sshdes.c sshdss.c sshecc.c sshhmac.c sshmd5.c sshrsa.c
sshsh256.c sshsh512.c sshsha.c sshsha3.c
ecc.c mpint.c
sshprng.c
sshcrc.c
sshdh.c sshmac.c
ssharcf.c sshblowf.c sshccp.c
sshblake2.c sshargon2.c sshbcrypt.c
cproxy.c)
add_library(network STATIC
Break up x11fwd.c. This is a module that I'd noticed in the past was too monolithic. There's a big pile of stub functions in uxpgnt.c that only have to be there because the implementation of true X11 _forwarding_ (i.e. actually managing a channel within an SSH connection), which Pageant doesn't need, was in the same module as more general X11-related utility functions which Pageant does need. So I've broken up this awkward monolith. Now x11fwd.c contains only the code that really does all go together for dealing with SSH X forwarding: the management of an X forwarding channel (including the vtables to make it behave as Channel at the SSH end and a Plug at the end that connects to the local X server), and the management of authorisation for those channels, including maintaining a tree234 of possible auth values and verifying the one we received. Most of the functions removed from this file have moved into the utils subdir, and also into the utils library (i.e. further down the link order), because they were basically just string and data processing. One exception is x11_setup_display, which parses a display string and returns a struct telling you everything about how to connect to it. That talks to the networking code (it does name lookups and makes a SockAddr), so it has to live in the network library rather than utils, and therefore it's not in the utils subdirectory either. The other exception is x11_get_screen_number, which it turned out nothing called at all! Apparently the job it used to do is now done as part of x11_setup_display. So I've just removed it completely.
2021-04-17 16:01:08 +00:00
be_misc.c nullplug.c errsock.c proxy.c logging.c x11disp.c)
Replace mkfiles.pl with a CMake build system. This brings various concrete advantages over the previous system: - consistent support for out-of-tree builds on all platforms - more thorough support for Visual Studio IDE project files - support for Ninja-based builds, which is particularly useful on Windows where the alternative nmake has no parallel option - a really simple set of build instructions that work the same way on all the major platforms (look how much shorter README is!) - better decoupling of the project configuration from the toolchain configuration, so that my Windows cross-building doesn't need (much) special treatment in CMakeLists.txt - configure-time tests on Windows as well as Linux, so that a lot of ad-hoc #ifdefs second-guessing a particular feature's presence from the compiler version can now be replaced by tests of the feature itself Also some longer-term software-engineering advantages: - other people have actually heard of CMake, so they'll be able to produce patches to the new build setup more easily - unlike the old mkfiles.pl, CMake is not my personal problem to maintain - most importantly, mkfiles.pl was just a horrible pile of unmaintainable cruft, which even I found it painful to make changes to or to use, and desperately needed throwing in the bin. I've already thrown away all the variants of it I had in other projects of mine, and was only delaying this one so we could make the 0.75 release branch first. This change comes with a noticeable build-level restructuring. The previous Recipe worked by compiling every object file exactly once, and then making each executable by linking a precisely specified subset of the same object files. But in CMake, that's not the natural way to work - if you write the obvious command that puts the same source file into two executable targets, CMake generates a makefile that compiles it once per target. That can be an advantage, because it gives you the freedom to compile it differently in each case (e.g. with a #define telling it which program it's part of). But in a project that has many executable targets and had carefully contrived to _never_ need to build any module more than once, all it does is bloat the build time pointlessly! To avoid slowing down the build by a large factor, I've put most of the modules of the code base into a collection of static libraries organised vaguely thematically (SSH, other backends, crypto, network, ...). That means all those modules can still be compiled just once each, because once each library is built it's reused unchanged for all the executable targets. One upside of this library-based structure is that now I don't have to manually specify exactly which objects go into which programs any more - it's enough to specify which libraries are needed, and the linker will figure out the fine detail automatically. So there's less maintenance to do in CMakeLists.txt when the source code changes. But that reorganisation also adds fragility, because of the trad Unix linker semantics of walking along the library list once each, so that cyclic references between your libraries will provoke link errors. The current setup builds successfully, but I suspect it only just manages it. (In particular, I've found that MinGW is the most finicky on this score of the Windows compilers I've tried building with. So I've included a MinGW test build in the new-look Buildscr, because otherwise I think there'd be a significant risk of introducing MinGW-only build failures due to library search order, which wasn't a risk in the previous library-free build organisation.) In the longer term I hope to be able to reduce the risk of that, via gradual reorganisation (in particular, breaking up too-monolithic modules, to reduce the risk of knock-on references when you included a module for function A and it also contains function B with an unsatisfied dependency you didn't really need). Ideally I want to reach a state in which the libraries all have sensibly described purposes, a clearly documented (partial) order in which they're permitted to depend on each other, and a specification of what stubs you have to put where if you're leaving one of them out (e.g. nocrypto) and what callbacks you have to define in your non-library objects to satisfy dependencies from things low in the stack (e.g. out_of_memory()). One thing that's gone completely missing in this migration, unfortunately, is the unfinished MacOS port linked against Quartz GTK. That's because it turned out that I can't currently build it myself, on my own Mac: my previous installation of GTK had bit-rotted as a side effect of an Xcode upgrade, and I haven't yet been able to persuade jhbuild to make me a new one. So I can't even build the MacOS port with the _old_ makefiles, and hence, I have no way of checking that the new ones also work. I hope to bring that port back to life at some point, but I don't want it to block the rest of this change.
2021-04-10 14:21:11 +00:00
add_library(keygen STATIC
millerrabin.c mpunsafe.c pockle.c primecandidate.c smallprimes.c
sshdssg.c sshecdsag.c sshprime.c sshrsag.c
import.c)
add_library(agent STATIC
sshpubk.c pageant.c aqsync.c)
add_library(guiterminal STATIC
terminal.c ldisc.c minibidi.c config.c dialog.c
$<TARGET_OBJECTS:logging>)
add_library(noterminal STATIC
noterm.c ldisc.c)
add_library(sshcommon OBJECT
ssh1bpp.c ssh1censor.c
ssh1connection.c ssh1login.c ssh2bpp-bare.c ssh2bpp.c ssh2censor.c
ssh2connection.c ssh2transhk.c ssh2transport.c ssh2userauth.c
sshcommon.c sshcrcda.c sshgssc.c sshpubk.c sshrand.c
sshverstring.c sshzlib.c
pgssapi.c portfwd.c x11fwd.c)
add_library(sftpcommon OBJECT
sftpcommon.c)
add_library(all-backends OBJECT
pinger.c)
add_library(sshclient STATIC
ssh1connection-client.c ssh2connection-client.c ssh2kex-client.c
sshshare.c ssh.c
mainchan.c agentf.c
$<TARGET_OBJECTS:sshcommon>
$<TARGET_OBJECTS:all-backends>
$<TARGET_OBJECTS:logging>)
add_library(sshserver STATIC
ssh1connection-server.c ssh1login-server.c ssh2connection-server.c
ssh2kex-server.c ssh2userauth-server.c sshserver.c
sesschan.c
sftpserver.c
$<TARGET_OBJECTS:sftpcommon>
$<TARGET_OBJECTS:sshcommon>)
add_library(sftpclient STATIC
psftpcommon.c sftp.c $<TARGET_OBJECTS:sftpcommon>)
add_library(otherbackends STATIC
telnet.c rlogin.c raw.c supdup.c
$<TARGET_OBJECTS:all-backends>
$<TARGET_OBJECTS:logging>)
add_executable(testcrypt
testcrypt.c sshpubk.c sshcrcda.c)
target_link_libraries(testcrypt
keygen crypto utils ${platform_libraries})
add_compile_definitions(HAVE_CMAKE_H)
foreach(subdir ${PLATFORM_SUBDIRS})
add_subdirectory(${subdir})
endforeach()
configure_file(cmake/cmake.h.in ${GENERATED_SOURCES_DIR}/cmake.h)
Reference in New Issue Copy Permalink