Non-recursive automake #128

Merged
merged 7 commits into from Oct 16, 2016

Projects

None yet

3 participants

@DrMcCoy
Member
DrMcCoy commented Sep 23, 2016

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
Contributor
berenm commented Sep 28, 2016

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
Member
DrMcCoy commented Sep 28, 2016

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
Contributor
berenm commented Sep 28, 2016 edited

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
Member
DrMcCoy commented Sep 28, 2016

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
jdm commented Sep 28, 2016

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.

DrMcCoy added some commits Sep 19, 2016
@DrMcCoy DrMcCoy VERSION: Move version.cpp from libcommon.la into its own libversion.la ecd6e3d
@DrMcCoy DrMcCoy BUILD: Suppress warning messages when there's no git directory a3367c3
@DrMcCoy DrMcCoy BUILD: Only display "GEN gitstamp" when the file is actually updated c24f7de
@DrMcCoy DrMcCoy BUILD: Use CLEANFILES for gitstamp instead of a custom clean rule f015730
@DrMcCoy DrMcCoy BUILD: Change the autotools setup to a non-recursive automake
Instead of recursive automake with subdirs, we're now using non-
recursive automake using (recursive) includes.

This should speed up parallel builds because these aren't blocked
across subdirectory boundaries anymore now. Dependency change
detection and therefore subsequent partial builds are also faster with
a non-recursive setup.

On the downside, the gitstamp hackery had to be reorganized, because
build order can't be predicted anymore now.

CMake building is currently still broken as well.
daa3d5f
@DrMcCoy DrMcCoy BUILD: Fix up the Automake -> CMake bridge again
Now that we're doing a non-recursive automake, the automake file
parser in our CMake scripts needed to be adapted for this as well.

The changes are as follows:
- Don't look in the configure anymore, instead specify the automake
  file to parse directly
- Handle include in the automake file, by recursively parse the
  included files and paste the result into the CMake file
- Don't prepend the full path onto source paths, as source paths are
  already fully path'd now
- Remove the extra src_ at the start of target names
- Since the gitstamp hackery is now in src/version/ instead of
  gitstamp/, we need to make sure its extra automake rule doesn't
  create non-parsable CMake, so we comment it out

The result seems to work, here on GNU/Linux at least.
68c9968
@DrMcCoy DrMcCoy VERSION: Encapsulate the version information more
They're now more opaque functions in the Version namespace.
2878f45
@DrMcCoy DrMcCoy merged commit 68c9968 into master Oct 16, 2016

4 checks passed

continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@DrMcCoy DrMcCoy deleted the nonrecursive branch Oct 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment