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

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On Fri 10 Apr 2015 10:10:13 PM SiegeLord 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.
> 
> 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).

I actually started working on the build box. It's not hard to get it to build 
allegro whenever we need. Some of the dependencies will be an issue, though 
once the VM for windows/MSVC is set up, it'd just keep using the same 
dependency versions till its manually updated, unless we want to auto update 
(not sure we do).

It would be handy to have a better way to build allegro and its dependencies 
with MSVC. Setting up the windows build instance is not something I'm looking 
forward to.

> -SL
> 
> ----------------------------------------------------------------------------
> -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx