Some bash scripts - Revision history

Slysven: /Update scripts/ Rename an environmental variable that is already used elsewhere

2024-04-13T22:28:33Z

Update scripts: Rename an environmental variable that is already used elsewhere

Slysven: Up

2024-04-13T22:23:07Z

Slysven: Correct error in URL for MSYS/Mingw-w64 homepage

2023-07-10T17:27:13Z

Correct error in URL for MSYS/Mingw-w64 homepage

Slysven: Updated zip file because of improvements in scripts in it

2023-07-08T23:26:29Z

Updated zip file because of improvements in scripts in it

Slysven: Updated zip file because of removal of Qt5 Gamepad usages in scripts in it

2023-05-01T16:47:09Z

Updated zip file because of removal of Qt5 Gamepad usages in scripts in it

Slysven: Updated zip file because of improvements in scripts in it

2023-04-23T16:06:12Z

Updated zip file because of improvements in scripts in it

Slysven: Revise for a later set (1.1) of scripts

2023-04-16T23:45:04Z

Revise for a later set (1.1) of scripts

Slysven: Refer to updated archive of the associated scripts

2023-04-16T23:39:34Z

Refer to updated archive of the associated scripts

Slysven: Initial entry about these Windows Mingw-w64 scripts

2023-04-10T23:05:14Z

Initial entry about these Windows Mingw-w64 scripts

New page

Go to [https://www.msys2.org/|the 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 [https://en.wikipedia.org/wiki/WoW64 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 [https://www.msys2.org/docs/environments/ 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 <tt>~</tt> character - in reality it is likely to be <tT>C:\msys64\home\YourWindows UserName</tT>, 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/a/a9/Mudlet_windows_build_scripts.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 <tt>echo $PATH</tt> in the terminal window to see what those are; typically the likely location would be to put them in a <tt>~/bin</tt> 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 <tt>ls -l</tt> 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:

:<tt>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 
:$</tt>

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

First run the <tt>setup-windows-sdk.sh</tt> script, 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 for those wishing to do more than just download and build Mudlet, but who also want to work on the code there are some extra files that can be uncommented (remove the '<tt>#</tt>'s and the text between the two blocks and put a '<tt>\</tt>' line-continuation marking in after the <tt>...luarocks</tt> item in that file):

<tt>

:"mingw-w64-${BUILDCOMPONENT}-lua51" \ 
:"mingw-w64-${BUILDCOMPONENT}-lua51-lpeg" \ 
:"mingw-w64-${BUILDCOMPONENT}-lua51-lsqlite3" \ 
:"mingw-w64-${BUILDCOMPONENT}-hunspell" \ 
:"mingw-w64-${BUILDCOMPONENT}-zlib" \ 
:"mingw-w64-${BUILDCOMPONENT}-boost" \ 
:"mingw-w64-${BUILDCOMPONENT}-yajl" \ 
:"mingw-w64-${BUILDCOMPONENT}-SDL2" \ 
:"mingw-w64-${BUILDCOMPONENT}-lua-luarocks" 
: 
:<nowiki># Optional extras for development:</nowiki> 
:<nowiki># "mingw-w64-${BUILDCOMPONENT}-ccache \</nowiki> 
:<nowiki># "mingw-w64-${BUILDCOMPONENT}-qt-creator \</nowiki> 
:<nowiki># "mingw-w64-${BUILDCOMPONENT}-qt5-doc \</nowiki> 
:<nowiki># "mingw-w64-${BUILDCOMPONENT}-cmake \</nowiki> 
:<nowiki># "mingw-w64-${BUILDCOMPONENT}-clang \</nowiki> 
:<nowiki># "mingw-w64-${BUILDCOMPONENT}-ninja</nowiki> 
:</tt>

It will fix a couple of current problems with the ''luarocks'' packages:
#that defaults to having the same location for rocks that are compiled to binary files (<tt>.dll</tt>s) when a per user "user" tree rather than a "system" one with the <tt>--tree "user"</tt> option is used. {The normal alternative for the "system"-wide locations for storage of installed lua modules built from rocks to <tt>luarocks</tt> of <tt>--local</tt> seems to be hard-coded to <tt>~/.luarocks</tt> 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.
#Until the Lua 5.4 version (currently) of the ''luafilesystem'' rock is installed, the <tt>luarocks</tt> program (and the related <tt>luarocks-admin</tt>) will both use a built-in Windows <tt>CMD.EXE MKDIR</tt> command to create directories - and that is not capable of creating missing "intermediate" directories, unlike the MSYS <tt>bash</tt> shell whose <tt>mkdir -p</tt> will do so silently and without complaint. So before using the <tt>luarocks</tt> command to <tt>build</tt> or <tt>install</tt> any Lua 5.'''1''' version modules for Mudlet to use, the 5.'''4''' <tt>luafilesystem</tt> 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 <tt>~/src/mudlet</tt> directory, and if one is not found it will clone the current [https://github.com/Mudlet/Mudlet.git 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 <tt>build-mudlet-for-windows.sh</tt> which will create a <tt>~/src/mudlet/build-MINGW32</tt> or <tt>~/src/mudlet/build-MINGW64</tt> 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 <tt>BUILD_TYPE</tt> to either <tt>release</tt> or <tt>debug</tt> - 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 <tt>WITH_OWN_QTKEYCHAIN</tt> as the MINGW64 environment already has that packaged but the MINGW32 does not; <tt>WITH_UPDATER</tt> is set to <tt>NO</tt> and <tt>WITH_MAIN_BUILD_SYSTEM</tt> is also set to <tt>NO</tt> as this is the precise environment (MSYS2/Mingw-w64) for which that option exists!} and then runs <tt>qmake</tt> to create the required ''MAKEFILE''s. If it is intended to do development work in this setup it is possible to use the <tt>ccache</tt> utility to cache compilation results which is ideal when switching between different points in the <tt>git</tt> repository. It has been found that setting the <tt>QMAKE_CC</tt> and <tt>QMAKE_CXX</tt> ''qmake'' variables to <tt>ccache gcc</tt> and <tt>ccache g++</tt> 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:

[[File:Using ccache in Qt Creator in Windows in a MINGW32 or 64 environment.png|frame 200x150px left|Using ccache in Qt Creator in Windows in a MINGW32 or 64 environment]]

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

After producing the makefile it will then run the <tt>mingw32-make</tt> 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 <tt>qmake</tt> 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 [https://doc.qt.io/qt-5/qmake-variable-reference.html#config CONFIG] variable, specifically the <tt>debug_and_release_target</tt> and <tt>debug_and_release</tt> 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 <tt>-k</tt> 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 <tt>package-mudlet-for-windows.sh</tt> will copy the <tt>mudlet.exe</tt> file (and the <tt>mudlet.exe.debug</tt> file for a ''debug'' type build) and place them in a directory <tt>~/src/mudlet/package-MINGW32|MINGW64-release|debug</tt> 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 <tt>.debug</tt> 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 <tt>Mudlet-MINGW32.zip</tt> or <tt>Mudlet-MINGW64.zip</tt> for the ''release'' builds or <tt>Mudlet-MINGW32-debug.zip</tt> or <tt>Mudlet-MINGW64-debug.zip</tt>) 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!

@@ Line 5: / Line 5: @@
 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 [https://www.msys2.org/docs/environments/ 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 <tt>~</tt> character - in reality it is likely to be <tT>C:\msys64\home\YourWindows UserName</tT>, 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/bb/Mudlet_windows_build_scripts_1_4.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 <tt>echo $PATH</tt> in the terminal window to see what those are; typically the likely location would be to put them in a <tt>~/bin</tt> 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 <tt>ls -l</tt> 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:
+Meanwhile download the scripts zipped up in this archive file: https://wiki.mudlet.org/images/d/d7/Mudlet_windows_build_scripts_1_5.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 <tt>echo $PATH</tt> in the terminal window to see what those are; typically the likely location would be to put them in a <tt>~/bin</tt> 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 <tt>ls -l</tt> 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:
 :<small><tt>stephen@Hunt MINGW64 ~/bin<br>

← Older revision		Revision as of 17:27, 10 July 2023
Line 1:		Line 1:
−	Go to [https://www.msys2.org/\|the 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.	+	Go to [https://www.msys2.org/ \|the 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 [https://en.wikipedia.org/wiki/WoW64 WindowsOnWindows64] environment provided on 64-Bit Windows OSes in which to run 32-Bit applications.		: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 [https://en.wikipedia.org/wiki/WoW64 WindowsOnWindows64] environment provided on 64-Bit Windows OSes in which to run 32-Bit applications.

@@ Line 5: / Line 5: @@
 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 [https://www.msys2.org/docs/environments/ 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 <tt>~</tt> character - in reality it is likely to be <tT>C:\msys64\home\YourWindows UserName</tT>, 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/3/33/Mudlet_windows_build_scripts_1_3.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 <tt>echo $PATH</tt> in the terminal window to see what those are; typically the likely location would be to put them in a <tt>~/bin</tt> 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 <tt>ls -l</tt> 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:
+Meanwhile download the scripts zipped up in this archive file: https://wiki.mudlet.org/images/b/bb/Mudlet_windows_build_scripts_1_4.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 <tt>echo $PATH</tt> in the terminal window to see what those are; typically the likely location would be to put them in a <tt>~/bin</tt> 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 <tt>ls -l</tt> 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:
 :<small><tt>stephen@Hunt MINGW64 ~/bin<br>

@@ Line 5: / Line 5: @@
 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 [https://www.msys2.org/docs/environments/ 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 <tt>~</tt> character - in reality it is likely to be <tT>C:\msys64\home\YourWindows UserName</tT>, 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 <tt>echo $PATH</tt> in the terminal window to see what those are; typically the likely location would be to put them in a <tt>~/bin</tt> 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 <tt>ls -l</tt> 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:
+Meanwhile download the scripts zipped up in this archive file: https://wiki.mudlet.org/images/3/33/Mudlet_windows_build_scripts_1_3.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 <tt>echo $PATH</tt> in the terminal window to see what those are; typically the likely location would be to put them in a <tt>~/bin</tt> 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 <tt>ls -l</tt> 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:
 :<small><tt>stephen@Hunt MINGW64 ~/bin<br>

@@ Line 5: / Line 5: @@
 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 [https://www.msys2.org/docs/environments/ 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 <tt>~</tt> character - in reality it is likely to be <tT>C:\msys64\home\YourWindows UserName</tT>, 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/d/d7/Mudlet_windows_build_scripts_1_1.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 <tt>echo $PATH</tt> in the terminal window to see what those are; typically the likely location would be to put them in a <tt>~/bin</tt> 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 <tt>ls -l</tt> 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:
+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 <tt>echo $PATH</tt> in the terminal window to see what those are; typically the likely location would be to put them in a <tt>~/bin</tt> 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 <tt>ls -l</tt> 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:
 :<small><tt>stephen@Hunt MINGW64 ~/bin<br>

@@ Line 25: / Line 25: @@
 #Until the Lua 5.4 version (currently) of the ''luafilesystem'' rock is installed, the <tt>luarocks</tt> program (and the related <tt>luarocks-admin</tt>) will both use a built-in Windows <tt>CMD.EXE MKDIR</tt> command to create directories - and that is not capable of creating missing "intermediate" directories, unlike the MSYS <tt>bash</tt> shell whose <tt>mkdir -p</tt> will do so silently and without complaint. So before using the <tt>luarocks</tt> command to <tt>build</tt> or <tt>install</tt> any Lua 5.'''1''' version modules for Mudlet to use, the 5.'''4''' <tt>luafilesystem</tt> 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 <tt>~/src/mudlet</tt> directory, and if one is not found it will clone the current [https://github.com/Mudlet/Mudlet.git 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.
+Finally this script checks for a <tt>~/src/mudlet</tt> directory, and if one is not found it will clone the current [https://github.com/Mudlet/Mudlet.git 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, so should a different branch be desired to be built it should be sufficient to checkout (and edit if wanted) the code before running the next script.
-Next it will be necessary to run the <tt>build-mudlet-for-windows.sh</tt> which will create a <tt>~/src/mudlet/build-MINGW32</tt> or <tt>~/src/mudlet/build-MINGW64</tt> 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 <tt>BUILD_TYPE</tt> to either <tt>release</tt> or <tt>debug</tt> - 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 <tt>WITH_OWN_QTKEYCHAIN</tt> as the MINGW64 environment already has that packaged but the MINGW32 does not; <tt>WITH_UPDATER</tt> is set to <tt>NO</tt> and <tt>WITH_MAIN_BUILD_SYSTEM</tt> is also set to <tt>NO</tt> as this is the precise environment (MSYS2/Mingw-w64) for which that option exists!} and then runs <tt>qmake</tt> to create the required ''MAKEFILE''s. If it is intended to do development work in this setup it is possible to use the <tt>ccache</tt> utility to cache compilation results which is ideal when switching between different points in the <tt>git</tt> repository. It has been found that setting the <tt>QMAKE_CC</tt> and <tt>QMAKE_CXX</tt> ''qmake'' variables to <tt>ccache gcc</tt> and <tt>ccache g++</tt> 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:
+Next it will be necessary to run the <tt>build-mudlet-for-windows.sh</tt> which will create a <tt>~/src/mudlet/build-MINGW32</tt> or <tt>~/src/mudlet/build-MINGW64</tt> 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 <tt>BUILD_CONFIG</tt> (was <tt>BUILD_TYPE</tt> in versions prior to 1.5.0 but that clashed with Mudlet's own CI/CB processes that also used a variable with that name for a different purpose) to either <tt>release</tt> or <tt>debug</tt> - 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 <tt>WITH_OWN_QTKEYCHAIN</tt> as the MINGW64 environment already has that packaged but the MINGW32 does not; <tt>WITH_UPDATER</tt> is set to <tt>NO</tt> and <tt>WITH_MAIN_BUILD_SYSTEM</tt> is also set to <tt>NO</tt> as this is the precise environment (MSYS2/Mingw-w64) for which that option exists!} and then runs <tt>qmake</tt> to create the required ''MAKEFILE''s. If it is intended to do development work in this setup it is possible to use the <tt>ccache</tt> utility to cache compilation results which is ideal when switching between different points in the <tt>git</tt> repository. It has been found that setting the <tt>QMAKE_CC</tt> and <tt>QMAKE_CXX</tt> ''qmake'' variables to <tt>ccache gcc</tt> and <tt>ccache g++</tt> 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:
 [[File:Using ccache in Qt Creator in Windows in a MINGW32 or 64 environment.png|frame 200x150px left|Using ccache in Qt Creator in Windows in a MINGW32 or 64 environment]]
-However, the same does NOT work when using <tt>qmake</tt> directly from a shell script.
+However, to get the when using <tt>qmake</tt> directly from a shell script a little manipulation of the ''MAKEFILES'' is needed and will be carried out by the script.
 After producing the makefile it will then run the <tt>mingw32-make</tt> 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 <tt>qmake</tt> 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 [https://doc.qt.io/qt-5/qmake-variable-reference.html#config CONFIG] variable, specifically the <tt>debug_and_release_target</tt> and <tt>debug_and_release</tt> 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 <tt>-k</tt> 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 <tt>package-mudlet-for-windows.sh</tt> will copy the <tt>mudlet.exe</tt> file (and the <tt>mudlet.exe.debug</tt> file for a ''debug'' type build) and place them in a directory <tt>~/src/mudlet/package-MINGW32|MINGW64-release|debug</tt> 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 <tt>.debug</tt> 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 <tt>Mudlet-MINGW32.zip</tt> or <tt>Mudlet-MINGW64.zip</tt> for the ''release'' builds or <tt>Mudlet-MINGW32-debug.zip</tt> or <tt>Mudlet-MINGW64-debug.zip</tt>) 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!
+Finally, once the build has been successfully completed the final script <tt>package-mudlet-for-windows.sh</tt> will copy the <tt>mudlet.exe</tt> file (and the <tt>mudlet.exe.debug</tt> file for a ''debug'' type build) and place them in a directory <tt>~/src/mudlet/package-MINGW32|MINGW64-release|debug</tt> 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 <tt>.debug</tt> 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 <tt>Mudlet-MINGW32.zip</tt> or <tt>Mudlet-MINGW64.zip</tt> for the ''release'' builds or <tt>Mudlet-MINGW32-debug.zip</tt> or <tt>Mudlet-MINGW64-debug.zip</tt>) 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!

@@ Line 19: / Line 19: @@
 :As they are ''bash'' script files they are purely text and can be opened and reviewed in a text editor.
-First run the <tt>setup-windows-sdk.sh</tt> script, 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 for those wishing to do more than just download and build Mudlet, but who also want to work on the code there are some extra files that can be uncommented (remove the '<tt>#</tt>'s and the text between the two blocks and put a '<tt>\</tt>' line-continuation marking in after the <tt>...luarocks</tt> item in that file):
+First run the <tt>setup-windows-sdk.sh</tt> 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:
 #that defaults to having the same location for rocks that are compiled to binary files (<tt>.dll</tt>s) when a per user "user" tree rather than a "system" one with the <tt>--tree "user"</tt> option is used. {The normal alternative for the "system"-wide locations for storage of installed lua modules built from rocks to <tt>luarocks</tt> of <tt>--local</tt> seems to be hard-coded to <tt>~/.luarocks</tt> 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.
 #Until the Lua 5.4 version (currently) of the ''luafilesystem'' rock is installed, the <tt>luarocks</tt> program (and the related <tt>luarocks-admin</tt>) will both use a built-in Windows <tt>CMD.EXE MKDIR</tt> command to create directories - and that is not capable of creating missing "intermediate" directories, unlike the MSYS <tt>bash</tt> shell whose <tt>mkdir -p</tt> will do so silently and without complaint. So before using the <tt>luarocks</tt> command to <tt>build</tt> or <tt>install</tt> any Lua 5.'''1''' version modules for Mudlet to use, the 5.'''4''' <tt>luafilesystem</tt> 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.

Some bash scripts - Revision history

Slysven: /*Update scripts*/ Rename an environmental variable that is already used elsewhere

Slysven: Up

Slysven: Correct error in URL for MSYS/Mingw-w64 homepage

Slysven: Updated zip file because of improvements in scripts in it

Slysven: Updated zip file because of removal of Qt5 Gamepad usages in scripts in it

Slysven: Updated zip file because of improvements in scripts in it

Slysven: Revise for a later set (1.1) of scripts

Slysven: Refer to updated archive of the associated scripts

Slysven: Initial entry about these Windows Mingw-w64 scripts

Slysven: /Update scripts/ Rename an environmental variable that is already used elsewhere