Non-recursive automake

[DrMcCoy]

Analoguously to the non-recursive PR in xoreos-tools, this changeset adds non-recursive automake support to xoreos.

The gitstamp hackery has to be redone for various reasons with a non-recursive setup. To remove the noise during the actual non-recursive change, this changeset front-loads a few related changes.

Likewise, the Automake -> CMake bridge has to be slightly redone. This is done in a separate commits.

No copyright header fixes here, though. :P

Comments welcome! :)

[berenm]

The CMake part looks OK to me, I am amazed that this horrible parser still does its job.

BTW I have been working on an appveyor.com integration so that Windows builds can also be automatically tested.

[DrMcCoy]

I am amazed that this horrible parser still does its job.

As long as it works, I'm pretty happy with it. :P

I have been working on an appveyor.com integration so that Windows builds can also be automatically tested

Oh, that would be very nice, yes. :)

Some checks with older compiler would be useful too, if in any way possible. The Windows and Mac OS cross-compilers I have set up here locally are relatively old gcc versions (especially the Mac OS one, a gcc 4.2.1, can't be updated without breaking the Apple stuff), but I only fire them up infrequently. The last time a few days ago I found some issues with missing includes that the newer gcc can resolve on its own somehow.

I've also been thinking about enabling CMake builds in Travis (i.e. do both, autotools and CMake). I think that should be possible by setting a custom variable in env, like USE_CMAKE. One env array item would set it to true, one to false. And then the build script itself would query that and use either CMake or autotools.

In combination with the compiler setting, that should then give use a 2x2 grid of builds:

• autotools, gcc
• autotools, clang
• CMake, gcc
• CMake, clang

This would ensure that I (or a PR or something) don't accidentally break either alternative without noticing.

In addition, I've also also started on writing unit tests, using Google Test. Still a non-public WIP branch here, but so far I already found some issues with it (the commits to common/ in the last few weeks, mainly). They're not completely clean, by-the-book unit tests (I'm not going to mock out UString in other checks and stuff like that), but I figured, it's better than nothing. That'll still take a while, though.

[berenm]

I have been working on an appveyor.com integration so that Windows builds
can also be automatically tested

Oh, that would be very nice, yes. :)

To be honest, I've been on it for quite some time... dependency management on Windows is absolutely horrible. However I think I'm seeing the end of it, thankfully because Microsoft seriously improved the C99 support in their latest releases of VS, so mostly all of xoreos dependencies can be rebuilt from source.

I'll make a PR at some point. Don't expect too much testing with older MSVC versions, I don't think it's possible.

I've also been thinking about enabling CMake builds in Travis (i.e. do
both, autotools and CMake). I think that should be possible by setting
a custom variable in env, like USE_CMAKE. One env array item would set it
to true, one to false. And then the build script itself would query that
and use either CMake or autotools.

In combination with the compiler setting, that should then give use a 2x2
grid of builds:

• autotools, gcc
• autotools, clang
• CMake, gcc
• CMake, clang

I guess you could reduce the matrix by one, I don't think trying both GCC and Clang on more than one build system will be very useful.

In addition, I've also also started on writing unit tests, using Google
Test. Still a non-public WIP branch here, but so far I already found some
issues with it (the commits to common/ in the last few weeks, mainly).
They're not completely clean, by-the-book unit tests (I'm not going to mock
out UString in other checks and stuff like that), but I figured, it's
better than nothing. That'll still take a while, though.

Nice!

[DrMcCoy]

dependency management on Windows is absolutely horrible

Ugh, yes. I already had one person give up in frustration while trying to get all the dependencies for xoreos on Windows. Boost especially gave them issues, IIRC. Losing potential contributors because of that is, well, frustrating as well.

Since Microsoft offers VMs for browser testing and things like that, I still have it on my TODO list to see if I can install Visual Studio on there and maybe create ready-made download packages with the dependencies for use in Visual Studio. Or something like that. Dunno.

I'll make a PR at some point.

I'll look forward to that, then.

I guess you could reduce the matrix by one, I don't think trying both GCC and Clang on more than one build system will be very useful.

Hmm, true.

[jdm]

No idea if it will help, but Servo has run the gauntlet of appveyor integration and came up with https://github.com/servo/servo/blob/master/appveyor.yml for our various dependencies.