Update actions to use libpcre2

[ryfactor]

No description provided.

[ryfactor]

I guess the scope of this has increased to updating the code that uses pcre's functions to however pcre2 does it. I'll take a look this weekend hopefully with a solution, unless someone else beats me to it.

[ryfactor]

Now the vm cannot find libpng. I guess I better update that next.

[ryfactor]

GNU 13.3 now throwing this error:

In file included from /home/runner/work/ivan/ivan/FeLib/Include/config.h:18,
                 from /home/runner/work/ivan/ivan/FeLib/Source/config.cpp:13:
In copy constructor ‘festring::festring(cfestring&)’,
    inlined from ‘festringpile::festringpile(cfestring&)’ at /home/runner/work/ivan/ivan/FeLib/Include/festring.h:145:37,
    inlined from ‘festringpile operator+(cfestring&, type) [with type = const char*]’ at /home/runner/work/ivan/ivan/FeLib/Include/festring.h:159:10,
    inlined from ‘static truth configsystem::NormalStringChangeInterface(stringoption*)’ at /home/runner/work/ivan/ivan/FeLib/Source/config.cpp:[23](https://github.com/Attnam/ivan/actions/runs/13045884947/job/36396279429?pr=661#step:6:24)7:31:
/home/runner/work/ivan/ivan/FeLib/Include/festring.h:172:7: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
  172 |       ++REFS(Data);

[ryfactor]

GNU 13.3 now throwing this error:
...

I was unable to reproduce this error in a devcontainer running ubuntu-24.04 with GNU 13.3.0.

GitHub must have shipped a bugged compiler with their ubuntu-latest runner, or I don't know what they've done. Furthermore, devcontainers and runners are not the same beast, making it very inconvenient to reproduce the same errors. So much for solving the "works on my (virtual) machine" issue.

[fliiiix]

@ryfactor is there something people can help with to push this over the finish line?

[ryfactor]

@fliiiix I think I can commit some time to this. What is your ideal time-frame to resolve?

[fliiiix]

I think the goal for nixpkgs is 26.11 (NixOS/nixpkgs#356387) I think so around october latest would be great - but i can upgrade the package whenever it is ready :)

[ryfactor]

@fliiiix I think I can work to that schedule, certainly that is plenty of time for me to fix the issue.

[zenorogue]

If I understand correctly, I am asked to review this. Looks good to me, and compiles correctly, although I do not know much about cmake or workflows. I have found one small issue: in INSTALL it is still written that "pcre, not pcre2" is a dependency.

[fliiiix]

Also a quick grep still shows some pcre in ci/osx

ci/osx/pcre.rb:  homepage "https://www.pcre.org/"
ci/osx/pcre.rb:    url "https://downloads.sourceforge.net/project/pcre/pcre/8.45/pcre-8.45.tar.bz2"
ci/osx/pcre.rb:    mirror "https://ftp.exim.org/pub/pcre/pcre-8.45.tar.bz2"
ci/osx/pcre.rb:    mirror "https://www.mirrorservice.org/sites/ftp.exim.org/pub/pcre/pcre-8.45.tar.bz2"
ci/osx/pcre.rb:    #url "https://ftp.pcre.org/pub/pcre/"
ci/osx/pcre.rb:    #regex(/href=.*?pcre[._-]v?(\d+(?:\.\d+)+)\.t/i)
ci/osx/pcre.rb:    url "svn://vcs.exim.org/pcre/code/trunk"
ci/osx/pcre.rb:      --enable-pcre8
ci/osx/pcre.rb:      --enable-pcre16
ci/osx/pcre.rb:      --enable-pcre32
ci/osx/pcre.rb:      --enable-pcregrep-libz
ci/osx/pcre.rb:      --enable-pcregrep-libbz2
ci/osx/pcre.rb:    system "#{bin}/pcregrep", "regular expression", "#{prefix}/README"
ci/osx/requirements.sh:  ## pcre and libpng are quiet stable, the CI servers can do better here
ci/osx/requirements.sh:    for formula in "${SCRIPT_DIR}"/{pcre,libpng}.rb; do
ci/osx/requirements.sh:    brew_install pcre libpng
ci/osx/requirements.sh:  brew_install pkg-config cmake pcre libpng sdl2 sdl2_mixer
ci/win/requirements.sh:    mxe-i686-w64-mingw32.static-pcre

But other than that nice to see this progress, as soon as this is merged i will take a look at updating the nix package ✨

Good work @ryfactor 👍