Hello Everyone!

TL;DR

I wanted a provisioning script for MinGW-w64 (since we NEVER have binary builds builds for A5/5.1 and -w64 ... or none seem to work for me) on Windows.

Repo: https://github.com/phrasz/A5_Installer/blob/master/Installer.ps1

Background

I wanted to shared this with everyone, since this update has been the bane of my existence over the last week. I've been toying around with a script I "released" a couple years ago, and I recently did an overhaul since I'm slowly coming back to allegro projects (I left the same time I released this to become smart on network stacks and MinGW-w64 ... and life just gets in the way at times). I "sorta" mentioned this a couple years back, but never really let everyone know that I shared it on GitHub: https://www.allegro.cc/forums/thread/613044.

I have done this because the POSIX large-file system Out of the Box makes MinGW just look silly. It actually builds via clever shell scripts through MSYS, but I used powershell just b/c two years ago, so I figured: why not?

How to Use it

The script actually is what I'd consider "mid-level" and has a TON of Q/A while running it. So what does the script do?: it points to the "latest" dependencies and tools, so that you can nearly blindly click next a bunch to get 5.1 allegro going.
It runs in three phases: Tools, Dependency, and A5 Sourcecode (git). The default configuration is to place everything in C:\AllegroEnv\. This is where I put MinGW and msys, but all the other tools are normal installs.

The script leverages WinBuilds to pull down MinGW-w64 and a TON of deps (which is actually most of what you need for allegro, but I was too lazy to hook into what is provided by WinBuilds).I dump MinGW-w64 into C:\AllegroEnv\MinGW-w64. This is also where you point to MinGW installer, which is ONLY used to install MSYS (you could change the references and target host configs to MinGW, and it should work as an FYI). Once you make it through these installs you could move on to deps/a5 source. BUT the catch to the script is you want to make sure all the "tools" are installed (MinGW-w64, MSYS, 7-zip, Git, and CMake) AND are on your PATH for the script to work. So if you want to use this script makes sure that `gcc --version`, `cmake --version`, `unzip --help`, `7z --help`, msys, and `git --version` work from powershell natively. Here's my Path entries as an example:

Once the tools are installed the second phase starts: the dependencies are collected from the Interwebs and placed into C:\AllegroEnv\Allegro5.1\A5_Deps. This script pulls EVERYTHING needed for building A5/5.1 and includes a pull of DX and Sal.h I saved LONG ago... The process is tricky (and where MSYS is needed). To make my life simple (and also to cheat and not need to learn more powershell) since it builds an "installer" *.sh script, places it in the MSYS "login" directory, and once all the dependencies installer scripts are made MSYS is fired up and all the deps are build automatically. Note DUMB is silly and still asks you to decide for inputs of MinGW and if you want allegro 4, so make sure you see the script note and hit M and N respectively. The real reason I went with MSYS: some deps don't use CMAKE, so you need a linux shell to execute CONFIGURE. I felt why not just all have them build the same way. Final note: all of these are configured to point to MinGW-w64 within the C:\AllegroEnv\MinGW-w64 folder. This means they are done in a make install fashion. I hate gathering and shoving files into allegro_src/deps ... so this is a lazy factor more than anything.

AFTER this is all done git is used to pull down the latest commit, and this is all placed into C:\AllegroEnv\Allegro5.1\SourceForge_src_5.1. YMMV!!! -- it DOES NOT checkout a tag ... it LITERALLY is the latest commit!!!. And MSYS is used once again to configure and build Allegro 5.1 (you arguably could change the code to use git to checkout any tag of interest ... but I like to live dangerously!). Both a static* and shared version are built and installed into MinGW-w64, and from this point you should simply be able to link against Allegro in "normal" windows ways. For a full blown CMD/Powershell approach I use:

*The static addition was late, and it builds the rolled up allegro "liballegro_monolith-static.a" lib fine, but I haven't found the linker options to resolve the gdi+ and opengl linking issues I've been having (there's also a primitives issue, but I gave up since I'm hooking against the shared libs). I have found `-lgdiplus -lgdi32 -lopengl32` has been "helping" but I'm shooting in the dark .

Ultimately, I will be using this, and if just the collection of commands can be leveraged by someone else having issues building on Windows my sharing the link served its purpose.

Issues (ignore if you aren't an advanced Allegro d00d)

Path Forward -- getting rid of Compiling on Windows...

I actually will be going "backwards" my super secret project has been working on this exact project, but its for the cross compiling toolchains as installed in Linux. That's right: I almost have working the Windows MinGW-w64 compiler as a cross compiler on LINUX. The idea is I'm done with a "compiler per system". Eventually I'm pushing ALL my allegro compilers into a Docker container and maintaining one thing for every platform (of course the issue there will be Mac). However, I had several issues with this (I actually was using the AUR Arch Linux installer and porting it to (*)ubuntu), which brought me back to the 2013 solution of powershell. What this week means for the Linux port: I've found issues with the windows compiler on windows that might actually allow me to re-look at my current issues with the linux version. Stay tuned ... I'm shooting for sooner than 2 years however! Ha!

More later
-Phrasz

Have you seen my harness from which I created the Windows binaries for 5.1.10? https://github.com/SiegeLord/allegro_winpkg

It has MSYS2 mingw-w64 package building for both 32 and 64 bits, but also comes with a 'universal' set of CMakeLists.txt projects to build all the dependencies for other compilers (I've only made scripts for MSVC). I'd love to get some scripts to build it for a 'generic' MinGW (failing that, a script for classic MinGW and mingw-w64 would be great too).