CI: test ./build_emulators.sh

[Arielfoever]

Add a build by build_emulators.sh and I believe there's no need to test.

[Arielfoever]

See #745

and somehow we need a mirror of gmp.

[Arielfoever]

Go and see https://github.com/Arielfoever/sail-riscv/actions/runs/14591059685/job/40926223320 if it works.

[jordancarlin]

Would be great to get this in, but I don't think this CI job will work until the issue with downloading GMP is addressed (#745 (comment)).

[jrtc27]

Building the simulator twice just to test the shell script seems quite wasteful, why not instead adapt the existing build job to use the script?

[jordancarlin]

That seems reasonable. If we want to make sure that the build works with both static and dynamic gmp, we could also have the build with the shell script happen on a weekly schedule instead of for every PR. Most code changes are unlikely to break it, so that is probably more than sufficient to make sure the script continues working.

[Arielfoever]

Would be great to get this in, but I don't think this CI job will work until the issue with downloading GMP is addressed (#745 (comment)).

Fix via #882

[Arielfoever]

Building the simulator twice just to test the shell script seems quite wasteful, why not instead adapt the existing build job to use the script?

I would agree with you but I suggest that put these two into repo for some time. When everything's fine we can remove another one.

[Arielfoever]

@Timmmm What is the problem? This is nothing to do with #882. This is CI not mirror.

[jordancarlin]

I think it was closed automatically by GitHub when #882 was merged because you put "fix #876" in the PR description (which GitHub picks up as a keyword to link PRs/issues). Reopened.

[github-actions]

Test Results

400 tests  ±0   400 ✅ ±0   2m 40s ⏱️ ±0s
  1 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit 28da50c. ± Comparison against base commit d9713b2.

♻️ This comment has been updated with latest results.

[Timmmm]

LGTM. I think it probably makes sense to make it be another job in compile.yml instead of a new file.

[Timmmm]

I think we don't need to upload the test results/event payload since the other workflow will already do this.

[arichardson]

This is duplicating quite a lot - can we just add another matrix combination to the main CI build?

I think something like this could possibly work?

    strategy:
      matrix:
        os: [macos-latest, ubuntu-latest]
        include:
          - os: ubuntu-latest
            variant: build-emulators

[Timmmm]

I think a variant might get complicated. We could potentially use composite actions to add it as a job without duplicating everything though. I've never used them before so I'm not really sure...

[Arielfoever]

I think a variant might get complicated. We could potentially use composite actions to add it as a job without duplicating everything though. I've never used them before so I'm not really sure...

I may try but deal with this one and #890 first

[jordancarlin]

Rather than adding a whole new job, what about updating the matrix in #952 so that one of the CMake versions uses the script for installation? That way, we are getting the benefit of testing the script without adding an ever-growing list of jobs to the CI.

I think it should be possible with something like this in place of the existing "Build and test simulators" step:

      - name: Build simulators
        if: ${{ ! matrix.use_script }}
        run: |
          cmake -S . -B build -GNinja -DCMAKE_BUILD_TYPE=RelWithDebInfo -DFIRST_PARTY_TESTS=TRUE
          ninja -C build all riscv_sim_rv32f riscv_sim_rv64f generated_smt_rv64f generated_docs_rv64d
      - name: Build simulators (with build_simulators.sh)
        if: ${{ matrix.use_script }}
        run: ./build_simulators.sh
      - name: Run Tests
        run: ctest --test-dir build --output-junit tests.xml --output-on-failure

[Arielfoever]

I suggest that this pr should add to tgmm to discuss about the version we want to test. @Timmmm

for instance,

• different cmake?
• different system like macos/windows/ubuntu2204/ubuntu2404
• remove old CI?
• different CI conditions.

I mentioned that there are a lot of diversions.