I am becoming concerned that the current way WASI binaries are built is problematic in that changes
we make to CMakeLists.txt may not be picked up. Since not all of us have the full Wasm build at hand,
it can cause difficulties and slow down development.

For example, I put a PR (#1984) to fix the CS_APIVERSION etc issue and I made a change to the
header source (version.h.in) and CMakeLists.txt. This was not picked up in the Wasm build and I
don’t have the means to fix it myself.

This also raises the concern that keeping two build systems in sync is maybe something we can’t
afford with so few active developers.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

Yes this is a concern and it's a known issue we need to modernize the wasm build. Unfortunately Hlodver isn't available much currently and I've been stuck spending a lot of time on PR reviews that I haven't had much time to do feature work. Ideally we'd move the nix build to use cmake. 

I pushed a fix for now to that PR. I also added a comment about major, minor, patch. I think we should remove APIVERSION (or now CS_APIVERSION and CS_APISUBVER) and just stick to semantic versioning practices (https://semver.org/) for major, minor, patch. 

On Sat, Oct 5, 2024 at 4:02 AM Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:

I am becoming concerned that the current way WASI binaries are built is problematic in that changes
we make to CMakeLists.txt may not be picked up. Since not all of us have the full Wasm build at hand,
it can cause difficulties and slow down development.

For example, I put a PR (#1984) to fix the CS_APIVERSION etc issue and I made a change to the
header source (version.h.in) and CMakeLists.txt. This was not picked up in the Wasm build and I
don’t have the means to fix it myself.

This also raises the concern that keeping two build systems in sync is maybe something we can’t
afford with so few active developers.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland

I do think a CMake build for the WASM targets is a very good idea. People tend to introduce dependencies such as a second build system without thinking if they can be avoided... I have been one of those people myself.

Regards,

Mike

-----------------------------------------------------

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Sat, Oct 5, 2024 at 3:21 PM Steven Yi <stevenyi@gmail.com> wrote:

Yes this is a concern and it's a known issue we need to modernize the wasm build. Unfortunately Hlodver isn't available much currently and I've been stuck spending a lot of time on PR reviews that I haven't had much time to do feature work. Ideally we'd move the nix build to use cmake. 

I pushed a fix for now to that PR. I also added a comment about major, minor, patch. I think we should remove APIVERSION (or now CS_APIVERSION and CS_APISUBVER) and just stick to semantic versioning practices (https://semver.org/) for major, minor, patch. 

On Sat, Oct 5, 2024 at 4:02 AM Victor Lazzarini <000010b17ddd988e-dmarc-request@listserv.heanet.ie> wrote:

I am becoming concerned that the current way WASI binaries are built is problematic in that changes
we make to CMakeLists.txt may not be picked up. Since not all of us have the full Wasm build at hand,
it can cause difficulties and slow down development.

For example, I put a PR (#1984) to fix the CS_APIVERSION etc issue and I made a change to the
header source (version.h.in) and CMakeLists.txt. This was not picked up in the Wasm build and I
don’t have the means to fix it myself.

This also raises the concern that keeping two build systems in sync is maybe something we can’t
afford with so few active developers.

========================
Prof. Victor Lazzarini
Maynooth University
Ireland