Re: [AD] Finding a solution to the Windows problem

[Elias Pschernig <elias.pschernig@xxxxxxxxxx>]

On Sat, Apr 11, 2015 at 7:10 AM, SiegeLord <siegelordex@xxxxxxxxxx> wrote:
> 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.

I wonder if we should ask Micał for his build scripts. However I think
those required quite a bit of manual work - I think he downloaded all
the upstream dependencies and his build scripts compiled all of them
as well as Allegro with each compiler (he supported several versions
of MSVC and mingw I think), ignoring any build systems Allegro or any
of the dependencies would have. As long as there's no package manager
that's probably the best option there is.

>
> 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.

Nuget sounds nice, I didn't know about it. Did you try compiling
Allegro with MSVC using nuget dependencies?

About mingw-w64, I don't think there's a good reason to provide
something else right now for us. It's not very hard to compile with
mingw (well, msys2/mingw-w64 at least) and so if you need some other
mingw for some reason, that option always remains.

>
> - 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.

I think it should work. But yes, there likely will be a few issues to
work out. But e.g. using Python Allegro, I managed to use the mingw
compiled .dll, despite Python for Windows being compiled with MSVC. Of
course using just runtime loading is a bit different from linking,
we'd at least have to provide import libraries and all of that but
mingw should have tools for that.

On a related note, we should fix our headers to work with any
platform. Right now you have to use the correct headers for each
compiler because of the way we distribute the config headers - but I
feel we should use compile-time checks there for some things instead
of cmake-time checks.

> 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).
>

I think we also should come up with a solution for OSX, it's not easy
compiling yourself there either.