Add Github CI

[bjosv]

Add Github CI and weekly builds to run tests with a range of different compilers and compiler versions on Ubuntu, Mac and Windows.

This PR includes:

• Updated minimum required CMake version from 2.8 to 2.8.12.2
• Fixes to build with GCC on Mac.
• Fixes to build with Clang 3.9, 4.0, 5.0
• Additional fixes in test for GCC 32-bit

[bjosv]

Just as a note, I cant (re)build 32bit and 64bit builds at the same time even using separate build-directories. It complains about the libflatccrt.a lib is incompatible, which is put in a common place /lib. I was just wondering about the debug/release variants could have some problem due to this..or maybe this has be thought thru already.

[mikkelfj]

No issue, debug uses libflatccrt_d.a

[mikkelfj]

I know someone once complained about binary naming. I don't recall exactly but I think it was wrt. installing 32 and 64 bit binaries into official distribution dirs on some Linux. I kind of rejected on grounds that current setup follows CMake convention, and a distribution can change naming/flags as needed.

[bjosv]

To avoid manually setup the build folders for 32bit builds it would be nice to use scripts/initbuild.sh to get the debug/release directories setup automagically, but I need to get the -m32 flags in there somehow.. Maybe we could add a new build.cfg.xxx flag that has something like FLATCC_BUILD_FLAGS="-DCMAKE_C_FLAGS=-m32 -DCMAKE_CXX_FLAGS=-m32" for initbuild.sh Not sure how it fits..

[mikkelfj]

I was thinking the same thing. It's just such a long time, so I don't remember anything. If you can add something to scripts/config, it would be great.

Note: the build kind of assumes the platform default, which by now is implicitly 64-bits. But it might not be for all users. This needs to be handled if making a specific 32-bit variant. This is also one reason why naming the builds to some specific beyond _d for debug is a bit tricky.

[mikkelfj]

We can also add an optional secondary flag to initbuild.sh for arch, but maybe its better to just keep it in the build cfg name.

[bjosv]

This works at least, and the -m32 flag should even work ok on an x86-32 according to link. WDYT?

Weekly: https://github.com/Nordix/flatcc/actions/runs/3498433077 CI: https://github.com/Nordix/flatcc/actions/runs/3498433065

[mikkelfj]

Me thinx this looks good. As long as it is understood that make-32bit is a Unix style build since flags likely won't work with Windows. With that in mind, README build section might need a comment.

[mikkelfj]

Any reason why Windows doesn't build in weekly?

[bjosv]

Only because of my lack of knowledge of building in windows :) I see now (if I understand correctly) that we only run VS 2015 in appveyor, so I guess there could be a range of different Visual studio versions used in weekly somehow.

[bjosv]

I see that setup-msbuild used in CI can take a VS version, I can look into that

[mikkelfj]

Yeah, the Appveyor required different build images for different versions after 64-bit became dominant. The ci-more should do something differently, but it isn't really ideal there anymore.

I was just thining having some Windows build such that we don't have to both run ci and weekly to be reasonably confident that the things largely works.

I might add more windows builds over time, but it's been a while since I looked into it.

[mikkelfj]

I suggest we just copy the Windows build to weekly for now, update README if relevant, then merge to master. After that we can polish the Windows build if possible.

[mikkelfj]

But I won't stop you if you have something better for Windows.

[bjosv]

Ok, seemed that it was not possible to get any version anyway, but For windows-latest or windows-2022 that will be Visual Studio 2022. And for windows-2019 that will be Visual Studio 2019

Can copy the job we have, and run on both images to get two VS versions at least.

[mikkelfj]

Also, you might want to update your initial PR comment since it isn't entirely up to date, yet rather specific.

[mikkelfj]

I have tested running builds on much older MSVC versions on GH actions, but it is a bit involved and some time ago, so I don't want to go into that for now. Also, it was not with CMake. But I have some material I can dig into.

[bjosv]

Perfect! I'll try to tying up the loose ends and finalize this later, or during the weekend, it's time for a beer now :)

[mikkelfj]

Great, and thanks again for the huge effort.

[bjosv]

Unfortunately the weekend flew by.., but here is the changes:

• Added Windows to weekly
• Added Mac Clang to weekly
• Some notes in README about the new build configuration available via initbuild.sh
• Simplified the inital PR comment

Example of Weekly: https://github.com/Nordix/flatcc/actions/runs/3513124399 CI: https://github.com/Nordix/flatcc/actions/runs/3513124396

[mikkelfj]

This looks good. Some quick observations:

Windows has warnings in pparsefp, likely due to changes I made - these warnings are also hard to find in GH actions - appveyor is much better at destilling these.

ci build seems to run Ubuntu 20, while this is relevant for some old test, we probably want to bump to 22 or so, if possible, for latest compiler tests?

icc compiler warnings appear to be concentrated on a single const expression warning, so perhaps we can find and disable that warning?

GCC 4.4 has the following warning: /home/runner/work/flatcc/flatcc/src/compiler/semantics.c:1549: warning: missing initializer /home/runner/work/flatcc/flatcc/src/compiler/semantics.c:1549: warning: (near initialization for ‘index..s.len’) Maybe not too important, but worth investigating.

Overall, I think this is good enough to merge now, what do you think?

[mikkelfj]

You can see the Appveyor warnings here: https://ci.appveyor.com/project/dvidelabs/flatcc/build/job/d6bt1ss79irvrt86/messages

Do you think GH Actions has some similar filter?

[mikkelfj]

Also, I think weekly.yml is currently set to build on push and pull requests.

[bjosv]

Ah, the warnings-tab in appveyor looks usable. I haven't seen any similar on GH Actions yet though.. I'll update to ubuntu22 in CI before we merge.

The on: in the files describes when to run the workflow, and in CI its on push and pull_requests. In weekly its on workflow_dispatch which enables manual runs of the workflow from the gui, and then the schedule. I had to add push and pull_request temporary when testing, but to me it looks like I managed to remove them before pushing to the PR branch. The examples are taken from the branch with the temporary change.

[mikkelfj]

I'm just thinking: I don't want weekly to run on PR because it takes too long for feedback, and trigger a lot of builds with frequent pushes, on other hand, it currently only takes 6 minutes to build, and I probably cannot trigger builds in PR branches since it is not my repo, or?

Most of the time I would assume things are good if ci.yml is good, but there might be cases where portability is more of a concern.

[bjosv]

You are probably right, I've never attempted to run a workflow manually on a PR before, so it might be problematic. Not sure..cant find any examples describing it either. This would for sure be nice to do when a PR is believed to affect a lot..

[mikkelfj]

Any idea how to add the ci.yml build to PR checks? I had this for Travis and Appveyor, and recently just Appveyor, but I am a bit at a loss how to enable this with GH actions?

[mikkelfj]

Or is it already enabled for future PRs? I don't see it on existing PRs.

[bjosv]

I believe it's only triggered by events, like new PRs or changes/push in existing PRs..

[bjosv]

So an update by committer or admin like this should make it run.

[mikkelfj]

OK, thanks, we'll see how it goes.