Pre-built release binaries?

[nightlark]

Would there be interest in having a CI workflow that builds (statically linked) Windows/macOS/Linux binaries for re2c/re2go and uploads them when a GitHub release is made?

The re2c binary seems like the main way of using re2c, so having a central place to grab the latest release binaries for common platforms would be nice instead of waiting for some of the update cycles for package managers (older Ubuntu releases being stuck on old versions of re2c, chocolatey package for Window being a few years outdated, etc).

[skvadrik]

Agreed, that would be useful. I think @sergeyklay wanted to do that as well.

[sergeyklay]

I apologize for completely forgetting this. My bad. I'll try to sort out asap.

[skvadrik]

No worries @sergeyklay, If you haven't started yet, maybe @nightlark was planning to work on this? Just trying to avoid duplicate effort.

[nightlark]

Yea I was thinking of starting on this, but I didn't find existing discussion about it on GitHub.

@sergeyklay if you already started something I can see about finishing it if you'd like. Otherwise, I can probably get a first pass at a workflow ready around this upcoming weekend.

[sergeyklay]

Unfortunately, I will not be able to find a free time in the next 4-5 days. And no, unfortunately I didn't even start.

That's what I think:

• Every CI run should produce binaries
• We should store these binaries in GitHub Artifacts
• On release event we should get latest binaries from GitHub Artifacts and attach theme to a release

@skvadrik thoughts?

[skvadrik]

I'm a bit worried if storing binaries on every CI run will waste too much space. We have retention-days: 30 but still those binaries won't be used. Maybe upload them only on release?

Aside from that, sounds good.

[nightlark]

An option to store the artifacts from a CI run could be added as a separate feature, and/or a nightly/weekly run of the release binary workflow could minimize the space used (I doubt re2c would run into artifact storage limits either way).

Would it be desirable to follow the bootstrapping process to regenerate the .re files before building the final release binaries? Or would building from e.g. a "distribution-ready" source tarball for the release be enough?

[skvadrik]

Would it be desirable to follow the bootstrapping process to regenerate the .re files before building the final release binaries?

Yes, I think we should build a minimal stage-1 and then a full stage-2. This is the way the current CI works. Here's where the Linux "fast" and "full" release builds are configured: https://github.com/skvadrik/re2c/blob/master/CMakePresets.json#L118-L133. And here they are used: https://github.com/skvadrik/re2c/blob/master/.github/workflows/ci.yml#L107-L126.

[sergeyklay]

@skvadrik Is the current configuration enough? Should we prepare a special CMake Preset with all possible optimizations to build production builds? A quick reminder: The current presets were designed only to meet the CI needs.

[sergeyklay]

Btw, there is a possibility reusing workflows available in public beta since October 5, 2021: https://docs.github.com/en/actions/learn-github-actions/reusing-workflows

So that we can reuse entire workflows as if they were an action.

[skvadrik]

Is the current configuration enough?

Almost. We need to enable re2go and disable docs:

  CMAKE_BUILD_TYPE="Release"
  CMAKE_CXX_COMPILER="g++"
  CMAKE_C_COMPILER="gcc"
  CMAKE_INSTALL_PREFIX:PATH="/home/runner/work/re2c/re2c/install"
  RE2C_BUILD_LIBS:BOOL="TRUE"
-  RE2C_BUILD_RE2GO:BOOL="FALSE"
+  RE2C_BUILD_RE2GO:BOOL="TRUE"
  RE2C_FOR_BUILD="/home/runner/work/re2c/re2c/install/bin/re2c"
-  RE2C_REBUILD_DOCS:BOOL="TRUE"
+  RE2C_REBUILD_DOCS:BOOL="FALSE"
  RE2C_REBUILD_LEXERS:BOOL="TRUE"

Enabling re2go on ci.yml is also fine, so we may want to have a preset inheritance chain "fast" <- "release" <- "full", where "full" just adds -DRE2C_REBUILD_DOCS:BOOL="TRUE".

[NickStrupat]

Is the idea to list the pre-built binaries in the releases? That would be ideal for my use case.

[skvadrik]

Is the idea to list the pre-built binaries in the releases?

Yes, the idea is to build statically linked binaries for every release on different platforms, and do that via GitHub Actions. (For clarity, I haven't done any work on this so far, the recent 3.0 release is without binaries.)

[PolarGoose]

As a workaround, I have created a repository to produce statically linked x64 executables of re2c for Windows:
https://github.com/PolarGoose/re2c-for-Windows

[pmetzger]

I think this would be very useful for windows, but is of much less interest on platforms like MacOS (where MacPorts or Brew will easily handle it for the user) or on most Linux platforms.