satellite

[mcandre]

Orbit above the build tool and automate more auxilliary build tasks in a platform-independent way.

[mcandre]

First, browse available scripting tools and task runners.

• make (GNU, BSD, p, d, n, etc.) Not portable. Assumes a (POSIX) shell, breaks in native COMSPEC Windows environments. People have a bad habit of adding bashisms there, too.

• (POSIX) sh, bash, ksh, zsh, [t]csh, ion, fish, vast are all fragile and have questionable Windows support.

Note that WSL does not offer sh as a reachable command from Command Prompt or PowerShell terminal sessions.

• batsh, PowerShell. Just no.
• ninja No conditionals.
• Mage (Go-specific, reasonably portable but not as portable as older systems).
• Shakefile (lol)
• Rake (gigantic installation)
• Maven/Gradle (gigantic installation) ((also just as bad at portable command line shell outs as make))
• Grunt, Gulp (gigantic installation)
• Invoke (gigantic installation) Also potentially conflicts with other Python needs, such as from common Python-based C/C++ linters.
• Rake (gigantic installation)
• Lua(Rocks)

Lua(Rocks) is a reasonably flexible, lean, fast, C/C++ interoperable language suitable for use as a basis for implementing a task runner system for C/C++ projects. Lua(Rocks) has overall good support for a variety of platforms. However, Lua(Rocks) may not necessarily have solid, first party, first tier support for some of the fringe platforms, suchas AIX, HP/UX, MirOS, OS/2 Warp, FreeDOS, MS-DOS, Android, iOS, and so on. Some platforms may not have a full, stable, modern LuaRocks release available. Some platforms may not even have a C++ compiler, or a C99 compiler. A task runner designed for intentely cross-platform use when developing software in a sea of Windows and UNIX build hosts, would be better served with a task runner built in and for C89. In the interest of not reinventing the wheel, we could begin by evaluating Lua build systems, sometimes known as build tools, sometimes known as task runners, before embarking on a pure C/C++ task runner.

Notably, Lua's platform support is comparable to cmake; If a platform can't build and run cmake, then it's already going to be difficult enough to manage C/C++ projects, nevermind the choice of task runner.

LuaRocks added support for distinguishing between packages required at runtime (dependencies) versus packages required during development (build_dependencies) in LuaRocks 3.0. Unfortunately, many OS package managers are stuck at a 2.x edition of LuaRocks, including Ubuntu and Chocolatey.

lenv ( https://github.com/mah0x211/lenv ) or luaver ( https://github.com/DhavalKapil/luaver ) may be able to assist with setting up Lua(Rocks) versions.

luaver was last updated in 2017, may break with newer Lua(Rocks) versions.

Note that lenv uses binaries instead of shell scripts. This limits platform support. Windows and FreeBSD are not currently supported by the binary releases.

• custom C/C++ task runner(s)

Any task runner whose tasks are written directly in C/C++ benefits from a reduced software stack, which can be more easily maintained and runs more efficiently compared to using secondary Python/Ruby/Lua/etc. languages. On the other hand, C/C++ are notorious for the sheer amount of boilerplate involved in getting anything done. We have many tradeoffs to make when deciding on a task runner for C/C++ projects.

Note that (POSIX) libc and (C++17) stdlibc++ have limited support for portable file system API functionality.

As a first pass, a pure by-and-for C task runner would suffice for C++ projects as well. We could generalize the design just enough to search for the root task in a C++ well known source file path, e.g. "tasks.cpp", and then fallback to "tasks.c". With the CXX and CC environment variables allowing for the user to flexibly work with Clang++, Clang, g++, gcc, and/or MSVC. No compiler toolchain vendor lock. And even mix and match with some projects that support multiple toolchains, like swiper.

Note that cmake and vcvarsall.bat manage MSVC environment variable loading. Any flexible C/C++ task runner that offers integration with the MSVC toolchain, will need a way to have the same environment variables loaded. For Vagrant-automated builds, this is trivial. For more common, interactive manual builds on a Command Prompt or PowerShell terminal session, this is far more annoying.

We could reverse engineer how cmake obtains these variables, once. But that is likely to break with future versions of MSVC.

Maybe there is a way to configure PowerShell to automatically load vsvarsall.bat in every terminal session. Ideally this includes noninteractive terminal sessions as well.

For interactive PowerShell sessions, there is. And it's gross.

https://superuser.com/a/886960/5142

What MSVC really needs is a direnv equivalent that can integrate with that system, allowing developers to specify with a CWD text file which MSVC version to load, on a per-project basis.

To the best of my knowledge, C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat, when present, loads environment variables for the host's default MSVC toolchain.

• cmake

cmake offers raw, uninterpreted shell commands (in many cases non-portable), and invoking shell scripts (fragile), and running plugins (cumbersome for writing many arbitrary tasks quickly). cmake can, however, build executables from ordinary C/C++ source files, which behave as the desired tasks. The overall workflow, for example, to solve the pain point of cmake's inability to easily remove all of its own junk files, would look like:

$ cmake .
$ cmake build . --target build-tasks
$ cmake build . --target super-clean

A bit cumbersome, but that would work.

Oh, and unfortunately the cmake use there as a task runner, would not be portable for the significant portion of C/C++ projects that don't use cmake as their build tool.

I've never liked how long cmake task commands are, by character count. Nor the divergent CLI syntax between cmake proper and ctest. Would prefer to wrap those. Without depending on (subjective, flaky, non-Windows, tty) shell aliases.

• cling (depends on clang)
• various other C/C++ interpreters
• autotools (lol)

autotools on Windows requires a Cygwin-style environment, such as WSL, Cygwin, MinGW, MSYS(Git), Git Bash, or Strawberry Perl. autotools likely lacks support for MSVC toolchains.

[mcandre]

lake

https://luarocks.org/modules/steved/lake

[mcandre]

conan recently improved support for clang-cl.

conan-io/conan#9295

We can reevaluate that for swiper and tonixxx. Possibility of dropping MSVC support altogether, which would simplify any non-cmake-based task runner implementation.

[mcandre]

rez