1
0
forked from cheng/wallet

Merge remote-tracking branch 'origin/cmake' into docs

This commit is contained in:
reaction.la 2022-07-08 17:07:18 +10:00
commit 5020bda29d
No known key found for this signature in database
GPG Key ID: 99914792148C8388
2 changed files with 39 additions and 12 deletions

2
.gitmodules vendored
View File

@ -9,4 +9,4 @@
[submodule "wxWidgets"]
path = wxWidgets
url = git@rho.la:~/wxWidgets.git
branch = rho-fork
branch = rho-fork

View File

@ -400,19 +400,46 @@ executed than in the past.
## The standard cmake installer from source
```bash
cmake .. && cmake --build && make && make install
After long and arduous struggle with CMake, I concluded:
That it is the hardest path from MSVC to linux.
That no one uses it as their first choice to go from linux to windows, so it
is likely to be a hard journey in the other direction.
I also found that the CMake scripting language was one of those
accidental languages.
CMakeLists.text was intended as a simple list of every file. And then one
feature after another was added, ad hoc, with no coherent plan and vision,
and eventurally so many features as to become Turing Complete, but like
most accidental turing complete languages, inconsistent, unpredictable, and
the code entirely opaque, and the whole way the developers did not
want their language to be used as a language.
CMake has gone down the wrong path, should have started with a known
language whose first class types are strings, list of strings, maps of
strings, maps of named maps of strings, and maps of maps, and CMake should
create a description of the build environment that it discovers, and a
description of the directory in which it was run in the native types of that
language, and attempt to create a hellow world program in that language
that invokes the compiler and the linker. Which program the developer
modifies as needed.
That MSVC's embrace of cmake is one of those embrace and extend
weirndesses, and will take you on a path to ever closer integration with
non free software, rather than off that path. Either that or the people
integrating it were just responding to an adhoc list of integration features.
That attempting a CMake build of the project using MSVC was a bad idea.
MingGW first, then MingGW integrated into vscode, in an all choco windows
environment without MSVC present.
```bat
choco install mingw pandoc git vscode gpg4win -y
```
To support this on linux, Cmakelists.txt needs to contain
```default
project (Test)
add_executable(test main.cpp)
install(TARGETS test)
```
On linux, `install(TARGETS test)` is equivalent to `install(TARGETS test DESTINATION bin)`
That Cmake does not really work all that well with the MSVC environment. If we eventually take the CMake path, it will be after wc and build on MingGW, not before.
## The standard Linux installer