search

Tectu / malloy

A cross-platform C++20 library providing embeddable server & client components for HTTP and WebSocket.
BSD 3-Clause "New" or "Revised" License
66 stars 8 forks source link

Enable CI for MinGW #27

Closed Tectu closed 3 years ago

Tectu commented 3 years ago

Add CI infrastructure to build this library on Windows using MinGW.

0x00002a commented 3 years ago

I'm working on this on and off. Is there a way to specify a specific version of a package in msys2? I'm having trouble getting the boost path to update when downloading the archive and I couldn't find a way to install specific boost versions via msys/pacman

Tectu commented 3 years ago

As far as I know, pacman (the package manager used by MSYS2) does not allow specifying package versions (easily).

Personally I don't think that we have to go through the trouble of doing a CI in an MSYS2 environment. Windows with MinGW should do it (along with cmake and the other utils necessary). MinGW itself can be installed using a regular installer: https://sourceforge.net/projects/mingw/

I don't have any experience working with Github actions - maybe they already provide some way of installing MinGW on a Windows machine? We're certainly not the only people using MinGW in a CI pipeline.

0x00002a commented 3 years ago

No but I suspect we are in the minority of people using mingw with github actions who also need c++20 support (i.e gcc 8.2.0 doesn't cut it). The choco package pulls from that source forge repo but the only build offering >8 doesn't have thread support.

Tectu commented 3 years ago

No experience with Github actions - We use jenkins & GoCD at our company. But something like this looks promising: https://github.com/marketplace/actions/install-mingw

MinGW-w64 is currently shipping with GCC 10.3 (which is also what I use to build this library on Windows). Should be fine, no? Am I missing something obvious here? ^^

0x00002a commented 3 years ago

Nope not obvious :p. That should install msys but I'm currently using this which is the one recommended by msys2 (docs). Problem is this part doesn't want to work because this gives a windows path like D:\a\malloy\... which msys2 doesn't like (7z cannot find the path). At least I think thats the problem :p.

Alternatively what I could do is just have it use the msys2 boost package. It wouldn't let us test specific versions but it would indicate whether the built failed with the latest msys2 which might be all we really need. I'd leave it disabled for now since it will always fail until the package updates to 1.76.

Also also, do you have an msys2/mingw build in jenkins or gocad? If so we could integrate those instead (I assume gocad has github integration?)

Tectu commented 3 years ago

[...] gives a windows path like D:\a\malloy... which msys2 doesn't like (7z cannot find the path). At least I think thats the problem :p.

is there a way to intercept the path(s) and do some awk/sed/grep to modify them? MSYS2 exposes Windows drives as /c, /d and so on instead of c:/ and d:/. Seems like an easy fix if there's a way to rewrite those somewhere.

Alternatively what I could do is just have it use the msys2 boost package. It wouldn't let us test specific versions but it would indicate whether the built failed with the latest msys2 which might be all we really need. I'd leave it disabled for now since it will always fail until the package updates to 1.76.

I think that would be a reasonable approach.

Also also, do you have an msys2/mingw build in jenkins or gocad? If so we could integrate those instead (I assume gocad has github integration?)

Yep, that is all there. My biggest problem there is that GoCD does not really provide a good means of accessing build status / logs outside the scope of an authenticated user (at least as per my knowledge). It's a CD system after all, not a CI system. We do have a Jenkins setup as well but we removed most of the build agents when we moved to GoCD.

0x00002a commented 3 years ago

is there a way to intercept the path(s) and do some awk/sed/grep to modify them? MSYS2 exposes Windows drives as /c, /d and so on instead of c:/ and d:/. Seems like an easy fix if there's a way to rewrite those somewhere.

Yes, yes there is :p I was already doing it for backslashes in the paths but I didn't think of doing it for the drive letters :woman_facepalming:. It now installs boost and configures correctly. However, on build, it looks like its not linking to the standard library

Tectu commented 3 years ago

It now installs boost and configures correctly. However, on build, it looks like its not linking to the standard library

I don't mean to be picky but if it does not link the STL I take it that the configuration didn't happen correctly? 😜 Just joking - Can you share the output of the config and the build stage?

0x00002a commented 3 years ago

This is the build: https://github.com/0x00002a/malloy/runs/2952650629?check_suite_focus=true and yes, true :p

Tectu commented 3 years ago

One thing that comes to mind (especially from past experiences when setting up Windows/MSYS2 build agents for Jenkings & GoCD: The commands (such as cmake and ninja) need to happen within the MSYS2 environment. The configuration stage reports:

System is unknown to cmake, create:

This smells a bit like that.

For jenkins this was rather easy as all I had to do is launching the Jenkins build agent (Java) within MSYS2: https://silizium.io/post/jenkins_msys2/

If I recall correctly, most CI/CD solutions execute calls through the OS' native command interface. In case of Windows that would be cmd.exe. This page is linked in my notes: https://www.msys2.org/wiki/Launchers/ This might be relevant/helpful too: https://stackoverflow.com/questions/26809898/invoke-msys2-shell-from-command-prompt-or-powershell

Obviously I can be completely wrong here.

0x00002a commented 3 years ago

Yep I needed the mingw version of cmake, and also to install base-devel (:woman_facepalming:)