Adding Fossil C Libraries target version 2.4.2

[dreamer-coding]

Adding Fossil C Libraries target version 2.4.2: Running this test through CI because my host system can't take the traffic.

[eli-schwartz]

Adding Fossil C Libraries target version 2.4.2: Running this test through CI because my host system can't take the traffic.

Enable GitHub Actions on your fork, then?

[dreamer-coding]

How can I create a valid hash value with the recommended sha256sha tool? how does on build_on work? How can I resolve this ToFu missing issue for two subprojects?

[benoit-pierre]

How can I resolve this ToFu missing issue for two subprojects?

Lower your C++ standard to a supported version, remove the use of werror=true (not a good default).

[dreamer-coding]

Alright, I made sure the repos were set to C18 before making the new releases, out of curiosity how does werror=true break the build?

[benoit-pierre]

Check the CI failures:

• https://github.com/mesonbuild/wrapdb/actions/runs/9224396351/job/25379576002?pr=1531#step:5:12124
• https://github.com/mesonbuild/wrapdb/actions/runs/9224396351/job/25379577191?pr=1531#step:6:96

[dreamer-coding]

The threads issue is gonna take a while to resolve, I will be opening an issue on that project regarding that, see about removing 'werror' as a default, but is it possible to disable werror for this build.

As for the second issue, I'm not sure how c18 could turn back to c2x after setting the new releases to c18 before creating them.

[benoit-pierre]

[…] but is it possible to disable werror for this build.

Override it in ci_config.json's build_options.

[dreamer-coding]

same format or do we do something else for built-in options?

[benoit-pierre]

Should be the same format.

[dreamer-coding]

While I'm applying that change, how does build_on work?

[benoit-pierre]

Yeah, I don't like how build_on work either…

If you have "msys2": false in build_on for example, it does not mean that the CI will not attempt to build for that platform. Instead, meson setup … is supposed to fail, but with a specific error message. See tools/sanity_checks.py.

[eli-schwartz]

For example liburing is a library that wraps the Linux kernel io-uring APIs, which means the source code isn't written to build or do anything on Windows.

[benoit-pierre]

What I don't like is the need for specific change to meson.build (example https://github.com/mesonbuild/wrapdb/pull/1144). IMHO, it would be better if that option was named fail_on, with the specific expected failure message.

[eli-schwartz]

Its intent is not to "shut up the CI", unfortunately we had to add it because people weren't responsibly using the option that previously existed.

Allowing people to choose the error message to look for would mean wraps that are broken due to being ill written would just catch the failure from the ill writing.

[benoit-pierre]

I agree, but I don't see why you'd need to add a specific error message to your meson.build when it's failing as expected, e.g. because a required header check is failing on an unsupported platform.

[dreamer-coding]

So it's kinda like a filter? What options?

What I don't like is the need for specific change to meson.build (example https://github.com/mesonbuild/wrapdb/pull/1144). IMHO, it would be better if that option was named fail_on, with the specific expected failure message.

I was thinking skip_on would be a clear name vs build_on since I don't see anyone using it to say what the package can build on.

[benoit-pierre]

Allowing people to choose the error message to look for would mean wraps that are broken due to being ill written would just catch the failure from the ill writing.

That's a review issue.

[eli-schwartz]

Allowing people to choose the error message to look for would mean wraps that are broken due to being ill written would just catch the failure from the ill writing.

That's a review issue.

I am devastated to have to say I agree with you.

We have review issues and this is how we prevented reviewers from recommending "just mark it as linux-only software for now".

[benoit-pierre]

Is forcing people to support platforms they don't care about a good thing? I resent having to spend so much time fixing Windows / macOS issues, platforms I don't care about. It certainly less work to keep some ports to myself then have to do the work of supporting those so I can PR them. That might be considered a loss for Linux users.

[dreamer-coding]

How can I resolve MSVC one of the main toolchains I hadn't compiled against yet? For Windows users, I made sure it worked with MSYS and MinGW natively which is possible since I have one of these Windows boxes and had tested with both of those tools.

[dreamer-coding]

Allowing people to choose the error message to look for would mean wraps that are broken due to being ill written would just catch the failure from the ill writing.

That's a review issue.

I am devastated to have to say I agree with you.

We have review issues and this is how we prevented reviewers from recommending "just mark it as linux-only software for now".

Perhaps two new fields would be of use. platforms and language, one for supported platforms, and the other for primary implementation language, if we're going for a package manager system supporting wraps for projects in mutable languages say someday someone starts adding wraps for rust or objective-c maybe d, how would a C++ or C developer know its, not a C or C++ library?

My workaround to identify the primary implementation is to add a tag at the end of each repo name like pizza-c for c, pizza-cpp, for cpp, pizza-objc for objective-c, and so on.

[eli-schwartz]

Is forcing people to support platforms they don't care about a good thing? I resent having to spend so much time fixing Windows / macOS issues, platforms I don't care about. It certainly less work to keep some ports to myself then have to do the work of supporting those so I can PR them. That might be considered a loss for Linux users.

I consider merging with failing CI to be superior to disabling CI. Disabling the CI means no one else who is interested in supporting Windows / macOS issues will not realize those issues exist.

For this reason, the CI now detects cases where disabling the CI was used in the erroneous belief that disabling CI resolves a blocker for merging. We return to a world where if the CI is failing you can say "CI is failing but it never worked on Windows anyway, this PR is an improvement over the previous stage of affairs, please merge".

"The perfect is the enemy of the good" and all that... but at least you should have a record that what you did was "good" but not "perfect".

CI failures in one wrap don't prevent the ability to get green checkmarks in another wrap. There's no reason to "avoid red checkmarks at all costs", we can and do use human judgment.

[eli-schwartz]

In this case it's not obvious to me that the CI was wrong to say CI shouldn't be disabled, since it did indeed manage to start passing on some builders with very minimal effort consisting of fixing meson.build mistakes.

[dreamer-coding]

I was just curious about build_on since there isn't really any documentation long along with a small description like some of the other attributes.

[dreamer-coding]

Speaking of CI being a good against perfect as a rule, why do we have skip_tests?

[dreamer-coding]

I suppose the last step is to update the libraries to compile to MSVC?

[dreamer-coding]

The MSVC seems to pass when I added it in a experimental pipeline, I'm pretty sure I'm probably missing something, how can I get this to mirror the expected MSVC environment?

name: Meson CI

on:
  push:
    paths:
      - "**.c"
      - "**.h"
      - "**.py"
      - "**.build"
      - "**.options"
  pull_request:
    paths:
      - "**.c"
      - "**.h"
      - "**.py"
      - "**.build"
      - "**.options"

jobs:
  build:
    name: Running on ${{ matrix.os }} with Meson v${{ matrix.meson_version }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-2022]
        meson_version: ["1.2.0", "1.3.0", "1.4.0"] # ensure no issues between Meson versions
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install Meson and Ninja on Linux and MacOS
        run: |
          python -m pip install --upgrade pip
          python -m pip install meson==${{ matrix.meson_version }} ninja

      - name: Configure
        run: meson setup builddir -Dwith_test=enabled

      - name: Compile
        run: meson compile -C builddir

      - name: Run Tests
        run: meson test -C builddir -v --test-args='--mode devops'

      - name: Upload Test Log
        uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: ${{ matrix.os }}_meson_testlog
          path: builddir/meson-logs/testlog.txt

  build_msvc:
    name: Running on Windows with MSVC
    runs-on: windows-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install Meson and Ninja
        run: |
          python -m pip install --upgrade pip
          python -m pip install meson ninja
          choco install visualstudio2019buildtools --package-parameters "--add Microsoft.VisualStudio.Workload.VCTools --includeRecommended --includeOptional --passive"

      - name: Configure
        run: meson setup builddir_msvc -Dwith_test=enabled

      - name: Compile
        run: meson compile -C builddir_msvc

      - name: Run Tests
        run: meson test -C builddir_msvc -v --test-args='--mode devops'

      - name: Upload Test Log
        uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: windows_msvc_meson_testlog
          path: builddir_msvc/meson-logs/testlog.txt

[dreamer-coding]

As a side question how do we handle updates for wrap files?

[benoit-pierre]

As a side question how do we handle updates for wrap files?

In which context?

[dreamer-coding]

lets say I do manage to get this approved and it's part of the database and later I release a new upstream version 3.0.0. How does the update process look when doing that?

[benoit-pierre]

• as far as updating WrapDB, the same steps as this PR: update the wrap, releases.json, and tweak until the CI pass
• for users meson wrap status, meson wrap update … can be used (the later will completely overwrite any changes to the wrap, like custom patches with diff_files = …)

[dreamer-coding]

what about the .wrap files?

[benoit-pierre]

what about the .wrap files?

I don't understand your question.

[dreamer-coding]

Let's draw a picture, so let's assume package gummy-bear.wrap is a thing and it's version 1.0, but then later gummy-bear.wrap for version 1.2 is available, do we archive the old version of gummy-bear.wrap or what happens?

[benoit-pierre]

Old versions are still available: https://mesonbuild.com/Wrapdb-projects.html.

[dreamer-coding]

Maybe you guys keep them in releases, I can see that being the case.

[dreamer-coding]

I'm no expert with the MSVC toolchain, how do I get this to point out the same issues your CI system found? Running it against my test framework and it thinks everything is fine which I don't believe for a half a millisecond, at least other parts of my new pipeline pointed out other issues like missing threads library:

  build_msvc:
    # if: github.event.pull_request.head.repo.full_name == 'fossil-lib/${{ github.event.repository.name }}'
    name: Running on Windows with MSVC
    runs-on: windows-latest
    strategy:
      matrix:
        msvc_version: [2015, 2017, 2019, 2022]
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install Meson and Ninja
        shell: pwsh
        run: |
          python -m pip install --upgrade pip
          python -m pip install meson ninja
          if ($env:msvc_version -eq "2015") {
            choco install visualstudio2015buildtools --package-parameters "--add Microsoft.VisualStudio.Component.VC.Tools.x86.x64 --includeRecommended --includeOptional --passive"
          } elseif ($env:msvc_version -eq "2017") {
            choco install visualstudio2017buildtools --package-parameters "--add Microsoft.VisualStudio.Workload.VCTools --includeRecommended --includeOptional --passive"
          } elseif ($env:msvc_version -eq "2019") {
            choco install visualstudio2019buildtools --package-parameters "--add Microsoft.VisualStudio.Workload.VCTools --includeRecommended --includeOptional --passive"
          } elseif ($env:msvc_version -eq "2022") {
            choco install visualstudio2022buildtools --package-parameters "--add Microsoft.VisualStudio.Workload.VCTools --includeRecommended --includeOptional --passive"
          }
          $env:CC="cl.exe"
          $env:CXX="cl.exe"

      - name: Configure
        run: meson setup builddir_msvc_${{ matrix.msvc_version }} --fatal-meson-warnings -Dwerror=true -Dwith_test=enabled

      - name: Compile
        run: meson compile -C builddir_msvc_${{ matrix.msvc_version }}

      - name: Run Tests
        run: meson test -C builddir_msvc_${{ matrix.msvc_version }} -v --test-args='--mode devops'

      - name: Upload Test Log
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: windows_msvc_${{ matrix.msvc_version }}_meson_testlog
          path: builddir_msvc_${{ matrix.msvc_version }}/meson-logs/testlog.txt

[dreamer-coding]

Does this system know to use the wraps already in the repos subprojects directories or do I need to tell it to not to look for host versions? and if so how?