Some bash scripts

Go to MSYS2 homepage and, following the instructions on that page, download and run its installer up until step 5 where a UCRT64 terminal will have been started for you.

Unfortunately only 64-Bit Windows 10 or later is supported nowadays for installation of this product. However it can be used to build 32-Bit products that can run on any Windows 10 (or later) systems, though that does impose a memory limit of just over 3GBytes, even within the WindowsOnWindows64 environment provided on 64-Bit Windows OSes in which to run 32-Bit applications.

Close that terminal because it is the wrong one for Mudlet right now. We will be using one of the other types either MING64 for 64-Bit builds or MINGW32 for 32-Bit one. For the details on the differences refer to MSYS2 environments. Open (you will find them on your Start menu) one of those two types of terminal as appropriate for what is wanted, you should find it will open in your MSYS2 "home" directory denoted by a ~ character - in reality it is likely to be C:\msys64\home\YourWindows UserName, however if your name cannot be represented in ASCII or maybe Latin-1 characters or if it has spaces in it then your mileage may vary going onwards!

Meanwhile download the scripts zipped up in this archive file: https://wiki.mudlet.org/images/b/b9/Mudlet_windows_build_scripts_1_2.zip and unzip them into a convenient location where they can be run from (most simply it could be one of the locations show in your path - type echo $PATH in the terminal window to see what those are; typically the likely location would be to put them in a ~/bin directory, though they can be anywhere if the full path to where they are compared to the current location in the file-system is given). Using ls -l in the chosen location check that they have execution permissions, signified by the 'x's in the attributes to the left in the listing output:

stephen@Hunt MINGW64 ~/bin

$ ls -l

total 36

-rwxr-xr-x 1 stephen stephen 6379 Apr 10 20:52 build-mudlet-for-windows.sh

-rwxr-xr-x 1 stephen stephen 13863 Apr 10 20:51 package-mudlet-for-windows.sh

-rwxr-xr-x 1 stephen stephen 8368 Apr 10 20:48 setup-windows-sdk.sh

stephen@Hunt MINGW64 ~/bin

$

As they are bash script files they are purely text and can be opened and reviewed in a text editor.

First run the setup-windows-sdk.sh script with one of either base or full as a command line option, it will check whether it is being run from a MINGW32 or MINGW64 terminal and install the additional packages currently needed to build that version of Mudlet. Note that the full option is for those wishing to do more than just download and build Mudlet, but who also want to work on the code as it will install some extra packages (including MSYS2/Mingw-w64's own build of the Qt Creator IDE - however that now only runs in a MINGW64 environment but can cross-compile a MINGW32 application if that is selected as a kit).

The script will also fix a couple of current problems with the luarocks packages:

1. that defaults to having the same location for rocks that are compiled to binary files (.dlls) when a per user "user" tree rather than a "system" one with the --tree "user" option is used. {The normal alternative for the "system"-wide locations for storage of installed lua modules built from rocks to luarocks of --local seems to be hard-coded to ~/.luarocks and that also suffers from the same problem in that if building for both 32- and 64-Bit builds of Mudlet the two different builds of the luarocks it fails to keep them separate and not mixed up.
2. Until the Lua 5.4 version (currently) of the luafilesystem rock is installed, the luarocks program (and the related luarocks-admin) will both use a built-in Windows CMD.EXE MKDIR command to create directories - and that is not capable of creating missing "intermediate" directories, unlike the MSYS bash shell whose mkdir -p will do so silently and without complaint. So before using the luarocks command to build or install any Lua 5.1 version modules for Mudlet to use, the 5.4 luafilesystem rock must be inserted into the system which may take more than one attempt with creating sub-directories needed that it cannot do itself whilst using it's defective native Windows command to create a directory.

Finally this script checks for a ~/src/mudlet directory, and if one is not found it will clone the current main Mudlet repository into that location. As things are currently configured this will checkout the current development branch code. If the directory already exists than this step is skipped.

Next it will be necessary to run the build-mudlet-for-windows.sh which will create a ~/src/mudlet/build-MINGW32 or ~/src/mudlet/build-MINGW64 directory as per the terminal type it is being run from. However the script needs to know whether to make a release or a debug type build which is to be specified by setting the environmental variable BUILD_TYPE to either release or debug - it will check and abort if that has not been done. After that, it configures some other environmental variables appropriate to the Mudlet build being done {specifically WITH_OWN_QTKEYCHAIN as the MINGW64 environment already has that packaged but the MINGW32 does not; WITH_UPDATER is set to NO and WITH_MAIN_BUILD_SYSTEM is also set to NO as this is the precise environment (MSYS2/Mingw-w64) for which that option exists!} and then runs qmake to create the required MAKEFILEs. If it is intended to do development work in this setup it is possible to use the ccache utility to cache compilation results which is ideal when switching between different points in the git repository. It has been found that setting the QMAKE_CC and QMAKE_CXX qmake variables to ccache gcc and ccache g++ in the appropriate place inside the Qt Creator project tab so that they appear in the effective qmake call is sufficient to get that tool working:

However, the same does NOT work when using qmake directly from a shell script.

After producing the makefile it will then run the mingw32-make command - which has that name for both MINGW32 and MINGW64 cases but is a different command from a different location in each. This should then compile and link all the object files for the selected build type. Due to the way that qmake functions in a MSYS2/Mingw-w64 environment release and debug builds are built in separate subdirectories of the build one which is at the same level as the source code. This is accounted for already in various internal file location dependent places and should not prove to be an issue (this can be researched in more detail by consulting the Qt Documentation about the CONFIG variable, specifically the debug_and_release_target and debug_and_release values which both default to being used in this environment. If the machine on which the build is being done is detected to have more than one processor cores then the make will be done using all of them and will also have the -k option set so that it keeps going to build as much as possible even if one or more files fail to compile.

Finally, one the build has been successfully completed the final script package-mudlet-for-windows.sh will copy the mudlet.exe file (and the mudlet.exe.debug file for a debug type build) and place them in a directory ~/src/mudlet/package-MINGW32|MINGW64-release|debug as appropriate and copy in all the other files that will be needed to run the Mudlet application in a stand-alone manner, even on another machine that does not have a MSYS2/Mingw-w64 installation. In the case of debug builds it also includes the .debug files for the Qt5 library files so that in the event of a crash in the main Mudlet code or the Qt framework it should be possible to identify the details of that crash. This is an advance over our current Windows builds. The downside to this is that, even after compressing all the files into an archive file that will be constructed in that directory (called Mudlet-MINGW32.zip or Mudlet-MINGW64.zip for the release builds or Mudlet-MINGW32-debug.zip or Mudlet-MINGW64-debug.zip) the debug versions are significantly larger e.g. for a build of recent development branch code in 64-Bits the release archive file was 62 MBytes but the debug one was 400MByte!