So as you guys are aware, Allegro has always had a bit of a Windows
problem. Unlike all other platforms, there just isn't a standard method
of building our dependencies or downloading them using a package
manager. This is a bit of a problem, since despite the rise of mobile
platforms (which comparatively are a lot easier to support, as both
build upon Unix environments), Windows is still very popular.
So I want to figure out how we can produce binaries for it. One of the
main difficulties is that this system must support MSVC, as it's just
too (undeservedly, imo) popular. This rules out the simple solution of
using mingw-w64 to cross compile everything from Linux. The mechanism we
decide upon will probably have to run from Windows (perhaps with a msys
shell). While it's relatively easy these days to build Allegro with
mingw, MSVC is an incredible pain still (I tried a few weeks ago and
gave up after a few hours). Ultimately, MSVC is the reason why we need
to make these binaries available.
Another requirement is that one day, it'd be nice to have weekly or
nightly builds. This will require a change in the build system, so this
is a more of a future improvement type of thing that our chosen option
hopefully doesn't rule out.
Here are some options I am considering:
- Don't distribute binaries, but instead work with mingw-w64's packagers
(mingw-w64 only) and Nuget (MSVC only) package managers to provide
Allegro packages. That only works if the necessary dependency packages
are available on those platforms, so we might have to take upon
ourselves to package some of the rarer dependencies (PhysFS and DUMB
probably fall under this). Also, it's not clear how to deal with nightly
builds. Lastly, mingw-w64, while being a great mingw distro, is not the
only one people use... but it's the only one with a package manager
worth its salt.
- Distribute binaries ourselves. This removes all the issues of
packaging, but probably requires us to write our own build systems for a
few of the dependencies (DUMB, libogg, libvorbis, libtheora come to
mind). I envision adding a CMakeLists.txt to all of them for uniformity
and MSVC compatibility.
- Figure out some way to make mingw-w64-produced binaries work with
MSVC. This might be tricky, as we use quite a bit of C++ under
Windows... but if it can be done, it'd simply things incredibly.
Any other ideas? I know Thomas was thinking of coming up with such a
system, but as far as I know that never left the planning stage. It
might be useful to use that hardware, perhaps, for nightly builds. It
probably doesn't really matter for regular builds (assuming the system
we come up with is automated enough to just-work on any Windows
installation).