You can sign built artifacts with cosign without actions or podman[-desktop]/docker.

It's probably possible to trigger gh actions or gl pipelines builds (container, command) with git repo mirroring.

datasette-lite depends on a WASM build of SQLite; what about WASM and e.g. emscripten-forge and micromamba?

Edit

emscripten-forge/recipes/recipes_emscripten/SQLite/build.sh: https://github.com/emscripten-forge/recipes/blob/main/recipe... ... recipe.yml says 2022: https://github.com/emscripten-forge/recipes/blob/main/recipe...

> Is it really desirable to have complex build tools be part of the project, especially after the xz-utils takeover?

That's a fair question, but i'm confident that in this case such a risk is simply not there. We've interacted with the maintainer of Autosetup and JimTCL (the same guy) for more than a decade and know he runs a proverbial "tight ship."

Autosetup has two major components:

- TCL-based scripts to process configure-style scripts and work with file templates in a way nearly identical to autotools (e.g. Makefile.in uses the same syntax).

- JimTCL is a TCL implementation which lives in the tree, allowing folks who won't have the canonical TCL installed to run the build.

Steve Bennett maintains both of those and is extremely conscientious about what goes into his trees.

Over the years, as we've updated our in-tree copy in the Fossil SCM, it's become habit to peruse the diffs of the upgraded files, comparing them to our previous install. In the unlikely case that someone were to sneak some mischief in, i'm fairly confident that we would catch it, at the latest, at that point (before checking in that change to our project).

To my eyes, the TCL that makes up configs for AutoSetup as well as the tool itself are much easier to read and audit than the M4 used in AutoTools projects. So I think this is an improvement. See the sources in FossilSCM for an example (auto.def file)

https://fossil-scm.org/home/tree?type=tree&ci=trunk

> > CMake is an out-of-tree tool, which is something the project tries to avoid at all costs for portability and maintainability reasons.

> Is this relevant though?

For this project and its day-to-day maintenance, unequivocally.

One of Richard's philosophies is "freedom means being able to take care of yourself," and that philosophy permeates all of his software projects, which eschew external dependencies because every single one reduces the project's level of freedom. Every time a third-party tool breaks, or introduces new, incompatible behavior as part of an upgrade, dependents of that tool suffer[^1]. All of Richard's projects have a strong culture of avoiding that suffering by avoiding third-party dependencies where at all possible, to the point of sometimes reinventing the wheel to extreme degrees (like implementing his own SCM).

That aspect aside, nobody in the SQLite project uses CMake, so it would never occur to us to migrate the build process to it. We write our own makefiles by hand _and we like it that way_. (Sidebar: Autosetup neither writes our makefiles nor introduces new syntax for doing so, in contrast to CMake.)

> I mean, there is no wrong in just coming forward and stating that you're already using a build system in another project and you're hoping to lower maintenance costs by standardizing on a single build system that you're already using. All other arguments sound dubious at best.

This isn't about standardizing on one build process, but about simplifying the lives of the developers and future maintenance of the project. We can't do that by porting to tools we don't otherwise use. If we weren't using Autosetup in other trees, and weren't happy with it, we wouldn't have even considered undertaking this effort and facing the downstream upheaval it will undoubtedly cause. We know, however, from 13 years of experience with it, that this tool does what we want, is low friction, and causes us an amount of grief which closely approaches zero[^2]. Without our collective background with Autosetup, we wouldn't have even considered porting away from the Autotools because that would be a case of "out of the frying pan and into the oven."

[^1]: As a concrete example: the SQLite project's WASM build is 100% dependent on the Emscripten toolchain for the simple reason that there is no feasible alternative. A handful of times over the past two years we have had to accommodate incompatible changes when upgrading Emscripten. That's hassle nobody wants. Obviously, software has to evolve, but being able to embed our build tools (Autosetup) directly in the source tree gives us control over the pace of that evolution. No system-wide upgrade is going to pull it out from under us, nor will it behave differently on downstream folks' machines.

[^2]: You won't ever hear me say that _any_ software is 100% grief-free, but autosetup is as close to it as, e.g., the bash shell.