Enhance CI building for Mingw-w64 (Part 1) #4071
Conversation
So that they show up in Qt Ctreator IDE! Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
This adds three shell scripts that try to replace some powershell ones to produce both 32 and 64-bit Windows packages. At present they should each produce a zip archive file containing all the files needed to execute the Mudlet application on a Windows PC that does NOT have MSYS2 installed in it. Further work is needed to get excecutable installers built from that set of files and to upload them to the *normal* location - at present they will be available as build artifacts on the AppVeyor CI platform... Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Hey there! Thanks for helping Mudlet improve. 🌟 Test versionsYou can directly test the changes here:
No need to install anything - just unzip and run. |
…able Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
in the past I had used a trick in a script to get past an issue caused by an overlarge font resources file that caused compilation failures. As that file is no longer present the explict mention of it broke things! Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
I thought I had (apart, obviously from the file extension as they are shell scripts {NOT |
SlySven
changed the title
|
after_build does what after_success does now, right? |
…uilds I had forgotton it! Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Not completely - I need it currently as that is the point at which the build artefacts (a .zip file) can be captured and made available in the AppVeyor build web-pages. It may be that |
|
Okay - well when it's ready, I'd like it to be consistent with other build system setup so the entire thing is easier to work on. |
So that the envirmental variables needed are available in all parts of the CI build. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Using the `--release` option breaks things! Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Oh blast, |
Because of the wrong order the script was using a `tr` from a non-MSYS2 element that is also present on the CI platform (Cygwin) and there was a dll mis-match. Also included a missing project related environment variable in the build environment that was needed. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
I had copy/pasted a script from the Travis CI arrangement and forgotten to tweak the CI variable names to suit! Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Windows non-standard URLs: |
|
Okay - main problem with those Windows builds is that they do not contain the Lua translation files that would be found in This might actually also be an issue for Linux packagers - as those files are NOT generated by the build process Just added another commit to address this issue! |
Also add them to qmake project file so that they show up in Qt Creator! Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Also upload to make.mudlet.org/snapshots instead of appveyor, that's what we use :) |
I don't seem to be having as much sucess with rsync as I had in the past, maybe because I was trying to be a bit more selective in my file selection. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…ravis] Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Python 2.x has finally left the MSYS2 / Mingw-w64 project - so we just need to specify python to get python 3.x as asking for python2 no longer works. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
`ntldd` was missing from package list but since I am now using it to identify the shared libraries that Mudlet needs besides the Qt and some other ones loaded dynamically. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
We are preferring it over the other one as it does not depend on zziplib. The other one missed getting into the previous commit for some reason. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…vis] The snapshot build code should now be complete. The PT builds should also work now. However the release build is still not complete. For testing purposes the NEXT commit should try and use SCP to upload the snapshot code so that it can be verified to be usable for the release builds - this needs some extra encryption stuff and a key (and salt) will probably need to be created to use the MSYS2 `scp` rather than the WINSCP NET module that the original PowerShell implimentation used. Includes a debug line to locate the secure-file utility that might be needed. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…[skip gha] [skip travis] Conflicts resolved in: * CI/travis.linux.after_success.sh * CI/travis.osx.after_success.sh Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
I had used an `end` instead of `fi` to close an `if` and https://www.shellcheck.net/ was helpful to find that AND strengthen all the AppVeyor scripts I have produced. IDEA: use it on the Linux and MacOs ones as well...! 8-) Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
When using native (to MSYS2) paths (with '/' directory separators) it is probably not necessary to use the $APPVAYOR_BUILD_DIR - we can hard code the path '/c/projects/mudlet/` which makes the quoting and processing of paths simpler - if harder to revise later one if that value ever changed. Also needed to fix some uses of `rsync` with a wild-card, especially when the path containing them is double-quoted. If rsync is processing the wildcard (instead of the shell?) it will stop at directories if a single `*` is used - apparently one needs to use s `**` to cause it to decend. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…vis] Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…ha] [skip travis] Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…vis] Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
…travis] Also swap 32 / 64 bit build job order to get results from latter first. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Also do not attempt to sign the Windows installer when we do not have the password - which we won't have in a PR testing build like the one that inserts this commit! Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Parts of this can only be tested AFTER it has been merged in the development branch because it uses some secure environment varables that are NOT present for PR/testing builds. HOWEVER ONCE IT HAS BEEN MERGED THINGS MUST BE REVERTED OR SUBQUENTLY REVISED BEFORE THE development BRANCH IS USED FOR A RELEASE BUILD. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
`pushd`/`popd` are bash shell built-ins and not present in a generic `sh`. The string equality test in a generic shell `test` is `=` nor `==`. One check for PT Builds used an old variable/logic which I had forgotten to update. Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
|
|
Not sure now if this is the way to go - Vadim seems to have |
Needed to pull in recent main line changes. Conflicts resolved in: * .appveyor.yml * src/mudlet.pro Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
Forgot that I had left this in place... 8-( Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
|
Alright, sounds good. We don't need a PR for this then, it can stay in a branch. |
This adds
threefour shell scripts that try to replace some PowerShell ones to produce both 32 and 64-bit Windows packages. At present they should each produce a zip archive file containing all the files needed to execute the Mudlet application on a Windows PC that does NOT have MSYS2 installed in it. Further work is needed to get executable installers built from that set of files and to upload them to the normal location - at present they will be available as build artefacts on the AppVeyor CI platform...Also: add some more existing files to QMake project file, so that they show up in the Qt Ctreator IDE!
Signed-off-by: Stephen Lyons slysven@virginmedia.com