Add: cross-build test for windows using LLVM-MinGW in Ubuntu. #288
Conversation
|
Why using LLVM-mingw instead of plain mingw?
|
Short Answer: it is the only way so far to support cross-compilation for Windows on Arm. |
| shell: bash | ||
| run: | | ||
| ## download llvm-MinGW | ||
| assetsUrl=$(wget -qO- https://github.com/mstorsjo/llvm-mingw/releases/latest | grep "expanded_assets" | grep -Po 'https[^"]+') |
There was a problem hiding this comment.
downloading each time seems too much, as far as I remember there's an option to store and re-use later
There was a problem hiding this comment.
It really doesn't matter, the source is in github, so it is as fast as using caches. Using caches is the method you mention, but it needs to download it no matter what as github store caches internally in .tar.xz format. So it won't be any faster.
I am using that method for nano for windows but for another reason. I use an optimized version of LLVM-MinGW there using musl under Alpine. So, I had to build my own tweaked version. I refresh the cache every week as it takes about 4 hours to build all the tools for all the environments.
There was a problem hiding this comment.
It really doesn't matter, the source is in github, so it is as fast as using caches.
Just out of interest: Do you have any docs that the "storage on github" is identical between the release artifacts and the caches? The first is reasonable to be kept with a CDN, while it makes more sense to keep the cache "as near as possible" to its single using worker(s).
There was a problem hiding this comment.
Checking back again - using caches (which also allows to check its state and drop the cache if necessary) really seems to be preferable. Please modify and we can pull this in.
|
BTW, why using appveyor??? Github actions can do the same in the same environment way faster than appveyor. You can even generate new versions and automate CI/CD, generate artifacts, pre-releases, and releases. |
|
Artifacts are now available for download. The first run is available here: https://github.com/okibcn/PDCursesMod.fork/actions/runs/4522282410#artifacts |
Because "back then" there was no GitHub actions available :-)
Note sure on that, the OpenWatcom builds take much less than 1 minute, same for VS arm64. @okibcn |
| export PATH="$LLVMBASE/bin:$PATH" | ||
|
|
||
| cd ${{ matrix.ENV }} | ||
| [[ "${{ matrix.UTF8 }}" == "Y" ]] && make -j$(nproc) demos ${{ matrix.ARCH }}=Y WIDE=Y UTF8=Y || make -j$(nproc) demos ${{ matrix.ARCH }}=Y |
There was a problem hiding this comment.
Thank you for adding UTF8/non-wide.
But actually there are three options:
- UTF8=Y (implies WIDE=Y)
- WIDE=Y (with the default UTF8=N)
- WIDE=N (the default)
Can you please add the missing option (second one) to the build matrix?
Aside from the lack of GitHub Actions at the time... I don't think there is a way to do (for example) the OpenWATCOM 1.9 and 2.0 compilations on GitHub Actions. I'm open to correction on that, though. While AppVeyor is really slow, it's been sufficient for our needs most of the time. But it'll be nice to be able to make good use of GHA and AppVeyor. I don't think it'll be an either/or choice. Very minor nitpick : in Simon's listing of the three character set options (wide, UTF-8 forced, eight-bit), that last involves "no options set". You can explicitly set |
Adds Xbuild matrixed Job with 11 additional build tests