4 ms·
> Conda-forge/sqlite-feedstock; recipe/meta.yml, Aside from the cross-compilation, which is most definitely part of the process but has not yet been explored i
by sgbeal 2y ago
> Conda-forge/sqlite-feedstock; recipe/meta.yml,
Aside from the cross-compilation, which is most definitely part of the process but has not yet been explored in depth[^1], nothing in your build immediately sticks out at as problematic, but i've bookmarked it for future reference during the port.
The .bat build (Windows) will not change via this port. Only Unix-like environments will potentially be affected.
> Is there a [multi-stage] Dockerfile to build, install and test SQLite with the new build system?
Not that the sqlite project maintains, no. None of us use docker in any capacity. We work only from the canonical source tree and we like to think that it's easy enough to do that other folks can too.
> Is there SLSA signing for the SQLite build artifacts?
That's out of scope for, and unrelated to, this particular sub-project.
> slsa-framework/slsa-github-generator: https://github.com/slsa-framework/slsa-github-generator https://github.com/slsa-framework/slsa-github-generator
says:
> This repository contains free tools to generate and verify SLSA Build Level 3 provenance for native GitHub projects using GitHub Actions.
We don't use github except to post a read-only mirror of the canonical source tree.
[^1]: Autosetup has strong support for cross-compilation, it just hasn't yet been tested in the being-ported build process.
- westurner 2y agoYou 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/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/recipes/recipes_emscripten/sqlite/recipe.yaml https://github.com/emscripten-forge/recipes/blob/main/recipe...
- sgbeal 2y ago> You can sign built artifacts with cosign without actions or podman[-desktop]/docker. That's all out of scope for, and unrelated to, this build port. > It's probably possible to trigger gh actions or gl pipelines builds (container, command) with git repo mirroring. We maintain our own SCM, which keeps us far removed from the github ways of doing things. None of the SQLite project members actively use github beyond posting the read-only project mirror and occasionally cloning other projects and/or participating in tickets, and that's unlikely to change in any foreseeable future. > emscripten-forge/recipes/recipes_emscripten/SQLite/build.sh: Thank you - bookmarked for later perusal and testing.
- westurner 2y agoSame. Thanks What about extensions; does the new build port affect extensions? /? hnlog sqlite (190+ mentions) From https://news.ycombinator.com/item?id=40837610#40842365 https://news.ycombinator.com/item?id=40837610#40842365 : - > There are many extensions of SQLite; rqlite (Raft in Go,), cr-sqlite (CRDT in C), postlite (Postgres wire protocol for SQLite), electricsql (Postgres), sqledge (Postgres), and also WASM: sqlite-wasm, sqlite-wasm-http, dqlite (Raft in Rust), awesome-sqlite
- sgbeal 2y ago> What about extensions; does the new bill port affect extensions? It won't, in any way, affect how third parties use the conventional project headers and amalgamated sources. It only has the potential to affect folks who use the "./configure && make" build process, as differences between the Autotools and Autosetup make it impossible to retain 100% semantic compatibility with the build processes (for reasons described one link removed from the forum post this HN post links to).
- deleted 2y ago[deleted]
- sgbeal 2y ago> The .bat build (Windows) will not change via this port. Only Unix-like environments will potentially be affected. It turns out that that's not _entirely_ true now: Richard got jimsh working on Windows, which means that nmake-driven Windows builds can now build SQLite (sans the testing suite) without requiring an extra installation of TCL.