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

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On Sun 12 Apr 2015 02:57:37 AM AJ wrote:
> pfft!  kids today...   aren't capable of reading 10 lines of
> instructions in a README.

It takes /hours/ for even a pro to compile allegro and all of its dependencies 
from scratch on windows. No joke. It's a pain in the ass.

> just make some tutorial videos of someone building allegro with mingw
> and stick it on you-tube.
> 
> i honestly believe this is probably far more valuable to noobs than any
> well worded README can ever be.
> 
> and don't skip over things that you think are trivial...   if it turns
> out to be a 30 mins video for what is to you and me a 5 min job, so be it.
> 
> i say mingw instead of MSVC, because it's something i know you can
> easily show how to install and have working in minimal steps and it's
> really hard to get wrong.. especially with those awesome mingw distros.
> 
> with MSVC, there are 5 versions.. each with different dialogs, and the
> typical user of msvc can't even tell you what a environment variable is!

I only intend on supporting one version.

> On 12/04/2015 2:04 AM, Thomas Fjellstrom wrote:
> > 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
> ----------------------------------------------------------------------------
> -- 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