Looking at cmake, choco, deb, git, and rust crates, I see a development environment being born, as people irregularly and ad hoc integrate with each other’s features.
Wine to run Windows 10 software under Linux is a bad idea, and Windows Subsystem for Linux to run Linux software under Windows 10 is a much worse idea – it is the usual “embrace and extend” evil plot by Microsoft against open source software, considerably less competently executed than in the past.
./configure && make && make installAfter 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.txt 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 eventually 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 hello 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 weirdness’s, 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.
choco install mingw pandoc git vscode gpg4win -yCmake 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.
Vscode has taken the correct path, for one always winds up with a full language and full program running the build from source, and they went with javascript. Javascript is an unworkable language that falls apart on any large complex program, but one can use typescript which compiles to javascript.
A full language is needed to govern the compile from source of a large complex program - and none of the ad hoc languages have proven very useful.
So, I now belatedly conclude the correct path is to build everthing under vscode.
On the other hand, the central attribute of both the makefile language and the cmake language is dependency scanning, and we shall have to see how good vscode’s toolset is at this big central job.
*.deb
debhelper and dh-make provide a somewhat user friendly tool for
making deb files.
*.deb files are commonly built from *.dsc files, which are also
available in the repository.
Which gives you the option, under debian, of building your entire
toolchain, something not possible in windows. It is half way to the
goal of building your own linux from scratch, without the elaborate
process where you type in a hundred commands, and if you
mistype a single one of them, everything goes to hell and you do
not know where in the process you went off the rails. But if you
want people to build from source, you probably want them to
develop, in which case git is better than *.dsc files
The standard deb file builder integrated into debian is git-buildpackage.
But other systems like a *.rpm package, which is built by git-buildpackage-rpm
But desktop integration is kind of random.
To put a program into the desktop applications menu, put its desktop file in
~/.local/share/applications (which may need to be created).
Under Mate and KDE Plasma, bitcoin implements run-on-login by generating a
bitcoin.desktop file and writing it into ~/.config/autostart
It does not, however, place the bitcoin.desktop file in any of the
expected other places. Should be in /usr/share/applications
The wasabi desktop file cat /usr/share/applications/wassabee.desktop is
[Desktop Entry]
Type=Application
Name=Wasabi Wallet
StartupWMClass=Wasabi Wallet
GenericName=Bitcoin Wallet
Comment=Privacy focused Bitcoin wallet.
Icon=wassabee
Terminal=false
Exec=wassabee
Categories=Office;Finance;
Keywords=bitcoin;wallet;crypto;blockchain;wasabi;privacy;anon;awesome;qwe;asd;To be in the menus for all users, should be in
/usr/share/applications with its Categories= entry set appropriately. Wasabi appears in the category Office on mate.
But what about the menu for just one user?
The documentation says ~/.local/share/applications. Which I
do not entirely trust.
Has a poorly documented and unexplained pipeline to *.deb files.
Plausibly cmake also has a pipeline, but I have not found it.
autotools is linux standard, is said to have a straightforward pipeline
into making *.deb files, and everyone uses it, including most of your
libraries, but I hear it cursed as a complex mess, and no one wants to
get into it. They find the far from easy cmake easier. And cmake
runs on all systems, while autotools only runs on linux.
MSYS2, which runs on Windows, supports autotools. So, maybe it does run on windows.
Despite the complaints about autotools, there is autotools documentation on the web that does not make it sound too bad.
I believe cmake has a straightforward pipeline into *.deb files,
but if it has, the autotools pipleline is far more common and widely used.
Requires an *.msi file. If the install is something other than an msi
file, it is broken.
Help Desk Geek reviews tools for creating *.msi
First and formost, Nullsoft Scriptable Install System (NSIS) Small, simple, and powerful.
Last and least Wix and Wax: it requires the biggest learning
curve. You can create some very complex installers with it, but you’ll be coding quite a bit and using a command line often.
And word on the internet is that complex installs created with
Wix and Wax create endless headaches and even if you get it
working in your unit test environment, it then breaks your
customer’s machine irreversibly and no one can figure out why.
NSIS can create msi files for windows, and is open source.
NSIS is also available as an MSYS package
People who know what they are doing seem to use this open source install system, and they write nice installs with it.
Unlike Wix, I hear no whining that any attempt to use its power will
leave you buggered and hopeless.
When I most recently checked, the most recent release was thirty five days previous, which is moderately impressive, given that their release process is somewhat painful and arduous.
Wix is suffering from bitrot. The wix toolset relies on a framework
that is no longer default installed on windows, and has not been for
a very very long time.
But no end of people say that sucky though it is, it is the standard way to create install files.
Hello World for Wix is startling nontrivial. It does not default create a minimal useful install for you. So even if you get it working, still looks like it is broken.
Common Design Flaws do not sound entirely like design flaws. It
sounds like it is easy to create *.msi files whose behaviour is
complex, unpredictable, unexpected, and apt to vary according to
circumstances on the target machine in incomprehensible and
unexpected ways. “Works great when we test it. Passes unit test.”
Some practical Wix advice advises that trying to do anything complicated on Wix is hell on wheels, and will lead to unending broken installs out in the field that fuck over the target systems.
While Wix in theory permits arbitrarily complex and powerful installs, in practice, no one succeeds.
“certain things are still coded on a case by case basis. These ad hoc solutions are implemented as ’custom actions` in Windows Installer,”
And custom actions that involve writing anything other than file properties, die horribly.
Attempts to install Wix on Visual Studio repeatedly failed, and sometimes trashed my Visual Studio installation.
After irreversibly destroying Visual Studio far too many times, attempted to install on a fresh clean virtual machine.
Clean install of Visual Studio on a vm worked, loaded my project, compiled and built it almost as fast as my real machine. The program it built ran fine and passed unit test. And then Visual Studio crashed on close. Investigating the hung Visual Studio, it had freed up almost all memory, and then just stopped running. Maybe the problem is not Wix bitrot, but Visual Studio bitrot, since I did not even get as far as trying to install Wix.
If the Wix installer is horribly broken, is it not likely that any install created by Wix will be horribly broken?
The Wix Toolset, requires the net framework 3.5 in order to install it and use it, which is the cobbler’s children going barefoot. You want a banana, and have to install a banana tree, a monkey, and a jungle.
Network Framework 3.5.1 can be installed with Control Panel/programs and programs/features.
You have to install the extension after the framework in that order, or else everything breaks. Or maybe everything just breaks anyway far too often and people develop superstitions about how to avoid such cases.
Choco, Chocolatey, is the Windows Package manager system. Does not use *.msi as its packaging system. A chocolatey package consists of an *.nuget, chocolateyInstall.ps1, chocolateyUninstall.ps1, and chocolateyBeforeModify.ps1 (the latter script is run before upgrade or uninstall, and is to reverse stuff done by is accompanying
chocolateyInstall.ps1)
Interaction with stuff installed by *.msi is apt to be bad.
The community distribution redirects requests to particular servers,
which have to be maintained by particular people - which requires
an 8GB ram, 50GB disk Windows server. I could have nginx in the
cloud reverse proxying that to a physically local server over
wireguard, which solves the certificate problem, or I could use a
commercial service, which is cheap, but leaks identity all over the
place and is likely to be subject to hostile interdiction and state sponsored identity theft.
Getting on the choco list is largely automatic. Your package has to
install on their standard image, which is a deliberately obsolete
2012 windows server - and your install script may have to install
windows update packages. Your package is unlikely to successfully
install until you have first tested it on an imitation of their test
environment, which is a great deal of work and skill to set up.
Human curation exists, but is normally routine and superficial.
Installs, has license, done.
Well, actually there are a whole lot more checks, which enforce a whole lot more rules, sixty eight rules and growing, but they are robotically checked and the outcome reported to human. If the robot OKs it, it normally goes through automatically into the community distribution.
A Choco package is immutable. Can be superseded, but cannot change. Could have the program check for a Zooko signature of its package file against a list, and look for indications of broad approval, thus solving the identity problem and eating my own dogfood.
Choco packages would be very handy to automatically install my build environment. ### Cmake
It is now apparent that CMake is the new standard. Unix makefiles
(.configure && make && make install) have become unworkable, are dying
under bitrot, and no one is maintaining them any more.
Every ide has its own replacement for makefiles, most of them also broken to a greater or lesser extent, and now ides are moving to CMake. If a folder has a CMakeLists.txt file in its root, or the CMake build file, it is a project, and the existing project files in the existing format are now obsolete, even though they will continue to be used for a very long time.
cmake has a pipeline for building choco files.
wxWidgets has instructions for building with Cmake. My other
libraries do not, and require their own idiosyncratic build scripts,
and I doubt that I can do what the authors were disinclined to do.
Presumably I could fix this with add_custom_target and
add_custom_command, where the custom command is bash script
that just invokes the author’s scripts, but I just do not understand
the documentation for these commands, which documentation
resupposes knowledge of the incomprehensible domain specific language.
Cmake runs on both Windows and Linux, and is a replacement for autotools, that runs only on Linux.
Going with cmake means you have a defined standard cross platform development environment,
vscode` which is wholly open source, and a defined standard cross platform packaging system,
or rather four somewhat equivalent standard packaging systems, two for each platform.
vscode has the worlds worst build system, but is now, like every ide, moving to cmake.
It is the build system that is the most important part of an ide – or it used to be, but now it is, or soon will be, the quality of its integration with cmake.
Instead of
./configure
make
make installcmake ..
cmake --build .
cmake --install .Which on windows is only going to work in the Visual Studio native tools command line environment.
cmake --install installs from source, and has a pipeline (cpack)
to generate *.msi through NSIS. Notice it does not have a pipeline
through Wix and Wax. It also has a pipeline to Choco, and, on linux,
to *.deb and *.rpm.
No uninstall, which has to be hand written for your distribution.
cmake has the huge advantage that with certain compilers, far from
all of them, it integrates with the vscode ide, including a graphical
debugger that runs on both windows and linux. Which otherwise
you really do not have on linux.
It thus provides maximum cross platform portability. On the other
hand, all of my libraries rely on .configure && make && make install
on linux, and on visual studio on Windows. In my previous
encounter with cmake, I found mighty good reason for doing it that
way. The domain specific language of CMakeLists.txt is arcane,
unreadable, unwriteable, and subject to frequent, arbitrary,
inconsistent, and illogical ad hoc change. It inexplicably does
remarkably complicated things without obvious reason or purpose,
which strange complexity usually does things you do not want.
Glancing through their development blog, I keep seeing major
breaking changes being corrected by further major breaking
changes. Internals are undocumented, subject to surprising change,
and likely to change further, and you have to keep editing them,
without any clearly knowable boundary between what is internal
stuff that you should not need to look at and edit, and what is the
external language that you are supposed to use to define what
cmake is supposed to accomplish. It is not obvious how to tell cmake to do a certain thing, and looking at a CmakeLists.txt file, not at all obvious what cmake is going to do. And when the next
version comes out, probably going to do something different.
But allegedly the domain specific language of ./configure has
grown a multitude of idiosyncrasies, making it even worse.
ccmake is a graphical tool that will do some editing of
CMakeLists.txt with respect for the mysterious undocumented
arcane syntax of the nowhere explained or documented domain
specific language.
reaction.la gpg key 154588427F2709CD9D7146B01C99BB982002C39F
This work is licensed under the Creative Commons Attribution 4.0 International License.