Skip to content

Enhance: move to msys2 and add64 bit windows build - take2#3255

Closed
SlySven wants to merge 2 commits intoMudlet:developmentfrom
SlySven:Enhance_moveToMSYS2AndAdd64BitWindowsBuild_take2
Closed

Enhance: move to msys2 and add64 bit windows build - take2#3255
SlySven wants to merge 2 commits intoMudlet:developmentfrom
SlySven:Enhance_moveToMSYS2AndAdd64BitWindowsBuild_take2

Conversation

@SlySven
Copy link
Copy Markdown
Member

@SlySven SlySven commented Dec 1, 2019

This commit is a squash and merge of a whole load of commits that I have edited the commit messages from:

The previous powershell scripts have been renamed to include "old" in them but I have chosen to use the older Windows cmd.exe to run MinGW32/64 bash terminals and to do the commands as bash scripts rather than
powershell ones.

I want to see how far the, now, two, builds get...

Move to invoking sh.exe direct from .appveyor.yml directly

Fix directory separators.

Flip and double some directory separators

Revise sh if tests

Revise pacman options

Reduce extent of pacman use - only install package

Don't do a system upgrade as that is likely to need a restart to achieve!

Switch to using the user (--local) rocktree for luarock as it seems we cannot access the system one because we are not privileged (administrator).

Try and find out which luarock is being a problem

Further lua tweaking and adding MSYS2 package cache

Tweak build directory settings

Fixup workaround for large font resource file

Change many uses of mingw32/64 to be set with variable

Try a different way to get the Lua configuration

Add some useful packages

I didn't realise that cat.exe was not in the base install but in coreutils and cygpath was in msys2-runtime. Also the location of some MSYS2 utilities was in /usr/bin and not /bin - which is probably a symlink to the former.

Implement a fix for broken luarocks in MINGW32 case

The /mingw32/share/lua/5.1/luarocks/site_config.lua file is malformed in comparison to the /mingw64/share/lua/5.1/luarocks/site_config.lua and this is enough to cause a luarocks invocation without any arguments to
report that the "system" configuration file is not present - which prevents system rocks to be installed.

Redo site_config.lua edit & add missing yajl package

Remove some now unused files and fix some code-factor warnings

The Windows executable is being saved but we still need to arrange for thebundle to be build and then distributed.

Import files needed and make Windows package archive

Tweak some paths and make packaging script run earlier

Make the zip archives have distinguishable names

Fixup: arrange for more needed MSYS2 packaged libraries to be included

As well as the OpenSSL needed for secure connections there were some graphics and compression libraries that also need to be included (some icons could not be shown on the connections dialogue). Also needed was the
SDL2 library that GamePad support needs.

  • libzstd.dll
  • liblzma-5.dll
  • libwebpdemux-2.dll
  • libwebp-7.dll
  • libtiff-5.dll
  • libjpeg-8.dll
  • libjasper-4.dll
  • libcrypto-1_1-x64.dll
  • libssl-1_1-x64.dll
  • SDL2.dll

BugFix: enable CMake builds to work on non-Windows platform

This PR is a distilled down replacement for #3208 .

Signed-off-by: Stephen Lyons slysven@virginmedia.com

This commit is a squash and merge of a whole load of commits that I have
edited the commit messages from:

The previous powershell scripts have been renamed to include "old" in them
but I have choosen to use the older Windows cmd.exe to run MinGW32/64
bash terminals and to do the commands as bash scripts rather than
powershell ones.

I want to see how far the, now, two, builds get...

Move to invoking sh.exe direct from .appveyor.yml directly

Fix directory separators.

Flip and double some directory separators

Revise sh if tests

Revise pacman options

Reduce extent of pacman use - only install package

Don't do a system upgrade as that is likely to need a restart to achieve!

switch to using the user (--local) rocktree for luarock as it seems we
cannot access the system one because we are not privileged (administrator).

Try and find out which luarock is being a problem

Further lua tweaking and adding MSYS2 package cache

Tweak build directory settings

Fixup workaround for large font resource file

Change many uses of mingw32/64 to be set with variable

Try a different way to get the Lua configuration

Add some useful packages

I didn't realise that cat.exe was not in the base install but in coreutils
and cygpath was in msys2-runtime. Also the location of some MSYS2 utilitys
was in `/usr/bin` and not `/bin` - which is probably a symlink to the
former.

Impliment a fix for broken luarocks in MINGW32 case

The `/mingw32/share/lua/5.1/luarocks/site_config.lua` file is malformed
in comparison to the `/mingw64/share/lua/5.1/luarocks/site_config.lua` and
this is enough to cause a `luarocks` invocation without any arguments to
report that the "system" configuration file is not present - which prevents
system rocks to be installed.

Redo site_config.lua edit & add missing yajl package

Remove some now unused files and fix some code-factor warnings

The Windows executable is being saved but we still need to arrange for the
bundle to be build and then distributed.

Import files needed and make Windows package archive

Tweak some paths and make packaging script run earlier

Make the zip archives have distinguishable names

Fixup: arrange for more needed MSYS packaged libraries to be included

As well as the OpenSSL needed for secure connections there were some
graphics and compression libraries that also need to be included (some
icons could not be shown on the connections dialogue). Also needed was the
SDL2 library that GamePad support needs.
libzstd.dll
liblzma-5.dll
libwebpdemux-2.dll
libwebp-7.dll
libtiff-5.dll
libjpeg-8.dll
libjasper-4.dll
libcrypto-1_1-x64.dll
libssl-1_1-x64.dll
SDL2.dll

BugFix: enable CMake builds to work on non-Windows platform

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
@add-deployment-links
Copy link
Copy Markdown

add-deployment-links bot commented Dec 1, 2019

Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

@SlySven SlySven changed the title Testing: try moving to MSYS2 based build of Win 32 & 64 bits Enhance: try moving to MSYS2 based build of Win 32 & 64 bits - take 2 Dec 1, 2019
@SlySven SlySven changed the title Enhance: try moving to MSYS2 based build of Win 32 & 64 bits - take 2 Enhance: move to msys2 and add64 bit windows build - take2 Dec 1, 2019
…Build_take2

This should remove a couple of files from the overall changes as the
development branch now has some changes that I cherry-picked over
from a different but now merged branch.

Signed-off by: Stephen Lyons <slysven@virginmedia.com>
@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Dec 3, 2019

Let us know when it's good to review, will hold off for now because it is Draft.

@SlySven
Copy link
Copy Markdown
Member Author

SlySven commented Dec 8, 2019

It correctly builds and positions two archives (one for 32-bit, one for 64-Bit) in a ${APPVEYOR_BUILD_FOLDER}\\package sub-directory - but I am not yet clear how to squirt them to the relevant places as PR test builds OR release versions (currently the update code is disabled for the 64-bit build to prevent difficulties but that can go one the release mechanism is in place to handle that).

I think I need to revise the scripts to handle the PR number for the testing case anyhow...

@SlySven
Copy link
Copy Markdown
Member Author

SlySven commented Dec 8, 2019

I would also have a knob in place so as to allow for debug (no optimisations, with debug info) builds to be produced as well as or instead of release (optimised, no debug info) ones - although it will double again the build time it might be worthwhile at least producing them for the proper RELEASE builds (i.e. no suffix on the version number) so that they can be used to help diagnose crashing issues on Windows releases...

@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Dec 8, 2019

Good idea, but how can they be used on Windows - users don't get a stacktrace?

edit: though that's not the scope of this PR, better to discuss this addition elsewhere...

@SlySven SlySven closed this Jun 22, 2020
@SlySven SlySven deleted the Enhance_moveToMSYS2AndAdd64BitWindowsBuild_take2 branch June 22, 2020 18:59
@SlySven SlySven restored the Enhance_moveToMSYS2AndAdd64BitWindowsBuild_take2 branch June 23, 2020 03:22
@SlySven
Copy link
Copy Markdown
Member Author

SlySven commented Jun 23, 2020

🤦 Accidentally deleted this branch whilst cleaning up a local repo mess - (pushed out a load of branches to GitHub rather than a local machine).

@keneanung
Copy link
Copy Markdown
Member

Maybe it helps, I wrote a script with an additional dependency (mingw-w64-<platform>-ntldd), that semi-automatically copies the required files together. Maybe it's a bit more robust than putting all dependencies into the script by hand.
deploy_msys2.zip

@vadi2
Copy link
Copy Markdown
Member

vadi2 commented Oct 7, 2020

Superceded by the more successful #4071.

@vadi2 vadi2 closed this Oct 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants