New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUILD: Add scripts to parse all Makefile.am and build with CMake. #57

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@berenm
Contributor

berenm commented Sep 24, 2014

As the other PR (#32) has been closed because of branch rewrite stuff, here it is again for the record.

This is the same AutoMake parsing stuff as before so that the CMake build system is automatically kept (more or less) in sync with the Autotools one.

There also is a separate commit for unit testing with Catch and a sample test suite for the TransformationMatrix class.

@cc9cii

This comment has been minimized.

Show comment
Hide comment
@cc9cii

cc9cii Apr 19, 2015

Contributor

This is great, thanks very much. I'm on windows and this PR allows me to get going (not that xoreos compiles with MSVC, it appears that system.h, filepath.h, etc needs some changes).

By the way, I'm using GUI version of CMake, v2.8.12.2. I had to make some changes, replacing [[ with " and adding extra escapes, etc.

EDIT: didn't realise that this PR was submitted last year. Why isn't it accepted/merged?

Contributor

cc9cii commented Apr 19, 2015

This is great, thanks very much. I'm on windows and this PR allows me to get going (not that xoreos compiles with MSVC, it appears that system.h, filepath.h, etc needs some changes).

By the way, I'm using GUI version of CMake, v2.8.12.2. I had to make some changes, replacing [[ with " and adding extra escapes, etc.

EDIT: didn't realise that this PR was submitted last year. Why isn't it accepted/merged?

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 19, 2015

Member

Why isn't it accepted/merged?

That's essentially down to me not liking CMake. At all. I like the idea of parsing the autotools files, and I'm really not happy with shutting out MSVC-using people either. But, yeah, I can't stand CMake, for various reasons I'm not going to get into again here.

I still [1] think the better solution is to take ScummVM's create_project, which spits out MSVC project files (even on non-Windows systems, something CMake doesn't for some reason) and adapt that to parse our autotools files.

[1] Even though it gets unlikelier by the day that someone interested in doing this comes along, unfortunately :/

not that xoreos compiles with MSVC, it appears that system.h, filepath.h, etc needs some changes

I would, however, be highly interested in what these changes are, and integrate those into the main xoreos tree. I don't have a running Windows, so I can't test any of this, and xoreos compiles fine into a Windows binary with a cross-compiling MinGW.

Member

DrMcCoy commented Apr 19, 2015

Why isn't it accepted/merged?

That's essentially down to me not liking CMake. At all. I like the idea of parsing the autotools files, and I'm really not happy with shutting out MSVC-using people either. But, yeah, I can't stand CMake, for various reasons I'm not going to get into again here.

I still [1] think the better solution is to take ScummVM's create_project, which spits out MSVC project files (even on non-Windows systems, something CMake doesn't for some reason) and adapt that to parse our autotools files.

[1] Even though it gets unlikelier by the day that someone interested in doing this comes along, unfortunately :/

not that xoreos compiles with MSVC, it appears that system.h, filepath.h, etc needs some changes

I would, however, be highly interested in what these changes are, and integrate those into the main xoreos tree. I don't have a running Windows, so I can't test any of this, and xoreos compiles fine into a Windows binary with a cross-compiling MinGW.

@berenm

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Apr 19, 2015

Contributor

By the way, I'm using GUI version of CMake, v2.8.12.2. I had to make some changes, replacing [[ with " and adding extra escapes, etc.

This is a syntax introduced in CMake 3.0.0, it was to avoid too much quote escaping in the strings.

Even though it gets unlikelier by the day that someone interested in doing this comes along, unfortunately :/

Probably because CMake does it well enough already, and that many people are using CMake, and very few are interested in writing build-system related code.

That's essentially down to me not liking CMake.

The configure step of this CMake PR takes around two second when the original autotools checks take almost a minute on my brand new SSD. Just trolling :).

Contributor

berenm commented Apr 19, 2015

By the way, I'm using GUI version of CMake, v2.8.12.2. I had to make some changes, replacing [[ with " and adding extra escapes, etc.

This is a syntax introduced in CMake 3.0.0, it was to avoid too much quote escaping in the strings.

Even though it gets unlikelier by the day that someone interested in doing this comes along, unfortunately :/

Probably because CMake does it well enough already, and that many people are using CMake, and very few are interested in writing build-system related code.

That's essentially down to me not liking CMake.

The configure step of this CMake PR takes around two second when the original autotools checks take almost a minute on my brand new SSD. Just trolling :).

@cc9cii

This comment has been minimized.

Show comment
Hide comment
@cc9cii

cc9cii Apr 19, 2015

Contributor

I would, however, be highly interested in what these changes are,

Sure, once I get things working I'll submit a PR. At the moment it's not quite working (2DA.zip is actually in Data directory)

C:\GOG Games\Neverwinter Nights 2 Complete>xoreos.exe -p.
WARNING: No target specified, but found a target with a matching path!
Target "xoreos"
Initialising shaders...
shader default/default.vert loaded
shader default/default.frag loaded
shader default/color.frag loaded
Initialising default surfaces...
Initialising default materials...
Initialising default mesh containers...
Graphics subsystem initialized
Sound subsystem initialized
Event subsystem initialized
Detected game "Neverwinter Nights 2"
[ 0%] Loading user game config
[ 5%] Declare string encodings
[ 10%] Setting base directory
[ 15%] Adding extra archive directories
[ 20%] Loading main resource files
Shutting down
ERROR: No such archive file "2da.zip"
Cleaning up shaders...

Contributor

cc9cii commented Apr 19, 2015

I would, however, be highly interested in what these changes are,

Sure, once I get things working I'll submit a PR. At the moment it's not quite working (2DA.zip is actually in Data directory)

C:\GOG Games\Neverwinter Nights 2 Complete>xoreos.exe -p.
WARNING: No target specified, but found a target with a matching path!
Target "xoreos"
Initialising shaders...
shader default/default.vert loaded
shader default/default.frag loaded
shader default/color.frag loaded
Initialising default surfaces...
Initialising default materials...
Initialising default mesh containers...
Graphics subsystem initialized
Sound subsystem initialized
Event subsystem initialized
Detected game "Neverwinter Nights 2"
[ 0%] Loading user game config
[ 5%] Declare string encodings
[ 10%] Setting base directory
[ 15%] Adding extra archive directories
[ 20%] Loading main resource files
Shutting down
ERROR: No such archive file "2da.zip"
Cleaning up shaders...

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 19, 2015

Member

The configure step of this CMake PR takes around two second when the original autotools checks take almost a minute on my brand new SSD

Yes, that's for the most part, down on boost.m4. Because it finds all different ways the boost libraries might be named and want to be linked with. And autotools checks for other libraries, too.

There's no way I can use the CMake thing for my cross-compiling MinGW, with statically linking boost, for example.

Member

DrMcCoy commented Apr 19, 2015

The configure step of this CMake PR takes around two second when the original autotools checks take almost a minute on my brand new SSD

Yes, that's for the most part, down on boost.m4. Because it finds all different ways the boost libraries might be named and want to be linked with. And autotools checks for other libraries, too.

There's no way I can use the CMake thing for my cross-compiling MinGW, with statically linking boost, for example.

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 19, 2015

Member

2DA.zip is actually in Data directory

Yes, and xoreos should be able to search through that. It does register the data directory as directory for ZIP resources files (see src/engines/nwn2/nwn2.cpp:201) At least it works here both on Linux, and with wine with the MinGW build...

There might be an issue with the filepath stuff. :/

Member

DrMcCoy commented Apr 19, 2015

2DA.zip is actually in Data directory

Yes, and xoreos should be able to search through that. It does register the data directory as directory for ZIP resources files (see src/engines/nwn2/nwn2.cpp:201) At least it works here both on Linux, and with wine with the MinGW build...

There might be an issue with the filepath stuff. :/

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 19, 2015

Member

At least it works here both on Linux, and with wine with the MinGW build...

Or maybe not. Just tried with a MinGW build in wine and it doesn't work anymore. It seems I recently broke that. My bad. :/

I'll fix it.

Member

DrMcCoy commented Apr 19, 2015

At least it works here both on Linux, and with wine with the MinGW build...

Or maybe not. Just tried with a MinGW build in wine and it doesn't work anymore. It seems I recently broke that. My bad. :/

I'll fix it.

@cc9cii

This comment has been minimized.

Show comment
Hide comment
@cc9cii

cc9cii Apr 19, 2015

Contributor

There's no way I can use the CMake thing for my cross-compiling MinGW, with statically linking boost, for example.

That should be possible with CMake (perhaps it is cross compiling that causes trouble?).

In any case, why can't autotools coexist with CMake? (I guess one reason might be people like me update exclusively on CMake and autotools miss out on updates/fixes ;-) But I don't know enough to update autotools so nothing is lost there ;-) :-D

Seriously, though, MSVC needs a bunch of additional stuff to get working properly and CMake just supports them better IMHO.

Contributor

cc9cii commented Apr 19, 2015

There's no way I can use the CMake thing for my cross-compiling MinGW, with statically linking boost, for example.

That should be possible with CMake (perhaps it is cross compiling that causes trouble?).

In any case, why can't autotools coexist with CMake? (I guess one reason might be people like me update exclusively on CMake and autotools miss out on updates/fixes ;-) But I don't know enough to update autotools so nothing is lost there ;-) :-D

Seriously, though, MSVC needs a bunch of additional stuff to get working properly and CMake just supports them better IMHO.

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 19, 2015

Member

Okay, with 16e9823, the problem of Windows not finding the archives should be fixed. It's a bit of a hacky way to use absolute() for, though, which is why it broke on Windows in the first place... I might need to rethink the whole shebang, again...

Member

DrMcCoy commented Apr 19, 2015

Okay, with 16e9823, the problem of Windows not finding the archives should be fixed. It's a bit of a hacky way to use absolute() for, though, which is why it broke on Windows in the first place... I might need to rethink the whole shebang, again...

@cc9cii

This comment has been minimized.

Show comment
Hide comment
@cc9cii

cc9cii Apr 20, 2015

Contributor

Confirming that your fix works. Thanks for that. Loads an internal cell but doesn't do much else (was there meant to be a menu that responds to mouse and/or keyboard?)

Contributor

cc9cii commented Apr 20, 2015

Confirming that your fix works. Thanks for that. Loads an internal cell but doesn't do much else (was there meant to be a menu that responds to mouse and/or keyboard?)

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 20, 2015

Member

Loads an internal cell but doesn't do much else

Yes, for NWN2, that's about it. You can open a debug console with Ctrl+D, though, and load other areas and modules.

was there meant to be a menu that responds to mouse and/or keyboard

Not for NWN2. We have a partial main menu for NWN, KotOR and KotOR2, and a partial ingame menu for NWN.

In NWN2, the menu definition is done by a XML files. Very, very broken and non-standard-compliant XML files. We need a custom parser for them first, because a stock XML library will throw errors left and right.

Member

DrMcCoy commented Apr 20, 2015

Loads an internal cell but doesn't do much else

Yes, for NWN2, that's about it. You can open a debug console with Ctrl+D, though, and load other areas and modules.

was there meant to be a menu that responds to mouse and/or keyboard

Not for NWN2. We have a partial main menu for NWN, KotOR and KotOR2, and a partial ingame menu for NWN.

In NWN2, the menu definition is done by a XML files. Very, very broken and non-standard-compliant XML files. We need a custom parser for them first, because a stock XML library will throw errors left and right.

@berenm

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Apr 20, 2015

Contributor

There's no way I can use the CMake thing for my cross-compiling MinGW, with statically linking boost, for example.

That should be possible with CMake (perhaps it is cross compiling that causes trouble?).

It is definitely possible, and quite easy, to cross compile with CMake. There are some platform toolchain descriptions, included in this PR, that can be used for cross-compilation.

Regarding Boost static link, it's probably a option to add. cmake --help-module FindBoost tells me that it could be controlled by Boost_USE_STATIC_LIBS option.

In any case, why can't autotools coexist with CMake? (I guess one reason might be people like me update exclusively on CMake and autotools miss out on updates/fixes ;-) But I don't know enough to update autotools so nothing is lost there ;-) :-D

This is how I meant this pull request to work. It parses the Automake descriptions to find targets, and as long as these files stay simple, CMake will not require duplicating the target descriptions. The only duplication is about library checks, and config.h generation, which is minimal.

The LLVM project for example, although they use a more complicated setup, have the same CMake / Autotools hybrid build system.

Contributor

berenm commented Apr 20, 2015

There's no way I can use the CMake thing for my cross-compiling MinGW, with statically linking boost, for example.

That should be possible with CMake (perhaps it is cross compiling that causes trouble?).

It is definitely possible, and quite easy, to cross compile with CMake. There are some platform toolchain descriptions, included in this PR, that can be used for cross-compilation.

Regarding Boost static link, it's probably a option to add. cmake --help-module FindBoost tells me that it could be controlled by Boost_USE_STATIC_LIBS option.

In any case, why can't autotools coexist with CMake? (I guess one reason might be people like me update exclusively on CMake and autotools miss out on updates/fixes ;-) But I don't know enough to update autotools so nothing is lost there ;-) :-D

This is how I meant this pull request to work. It parses the Automake descriptions to find targets, and as long as these files stay simple, CMake will not require duplicating the target descriptions. The only duplication is about library checks, and config.h generation, which is minimal.

The LLVM project for example, although they use a more complicated setup, have the same CMake / Autotools hybrid build system.

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 20, 2015

Member

Yes, for NWN2, that's about it

Oh, and you can "fly" through NWN2 areas in a kind of spectator mode. WASD for movement; middle mouse button + mouse move = camera rotate; Q, E, page up, page down also rotate the camera.

Member

DrMcCoy commented Apr 20, 2015

Yes, for NWN2, that's about it

Oh, and you can "fly" through NWN2 areas in a kind of spectator mode. WASD for movement; middle mouse button + mouse move = camera rotate; Q, E, page up, page down also rotate the camera.

Show outdated Hide outdated .gitignore
@@ -46,5 +46,6 @@ INSTALL
/gitstamp/gitstamp
# Unix binary
/src/xoreos
# Window binary

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

This changeset doesn't belong here.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

This changeset doesn't belong here.

Show outdated Hide outdated CMakeLists.txt
list(APPEND XOREOS_LIBRARIES ${GLEW_LIBRARIES})
find_package(Lua51)

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

I'm not sure we actually ever want a system Lua instead of our own. We have to support the Witcher scripts, which are compiled, and therefore pinned to a specific Lua version. And we will probably need to hack the loader anyway, to do icky stuff to the bytecode (endianess changes, for one thing).

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

I'm not sure we actually ever want a system Lua instead of our own. We have to support the Witcher scripts, which are compiled, and therefore pinned to a specific Lua version. And we will probably need to hack the loader anyway, to do icky stuff to the bytecode (endianess changes, for one thing).

This comment has been minimized.

@turol

turol Apr 20, 2015

32- and 64-bit Lua bytecodes are not compatible either so you'll have to find a workaround for that too.

@turol

turol Apr 20, 2015

32- and 64-bit Lua bytecodes are not compatible either so you'll have to find a workaround for that too.

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

Yeah, I'm already dreading that...

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

Yeah, I'm already dreading that...

Show outdated Hide outdated CMakeLists.txt
set(CPACK_PACKAGE_NAME ${PROJECT_NAME})
set(CPACK_PACKAGE_VERSION ${xoreos_VERSION})
set(CPACK_PACKAGE_CONTACT "Sven Hesse <drmccoy@drmccoy.de>")

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

I think that contact should rather by the mailing list at xoreos-devel@xoreos.org, no?

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

I think that contact should rather by the mailing list at xoreos-devel@xoreos.org, no?

This comment has been minimized.

@berenm

berenm Apr 20, 2015

Contributor

Well, I'm not sure if packaging even has to be supported by the CMake toolchain. It was to be on-par with autotools but maybe not useful.

@berenm

berenm Apr 20, 2015

Contributor

Well, I'm not sure if packaging even has to be supported by the CMake toolchain. It was to be on-par with autotools but maybe not useful.

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

True. Hell, I haven't really thought much about proper packing anyway. That's not something we're ready for yet. :P

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

True. Hell, I haven't really thought much about proper packing anyway. That's not something we're ready for yet. :P

Show outdated Hide outdated CMakeLists.txt
set(CPACK_PACKAGE_CONTACT "Sven Hesse <drmccoy@drmccoy.de>")
set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Xoreos Engine: A new implementation of BioWare's Aurora engine.")
set(CPACK_PACKAGE_DESCRIPTION "Xoreos Engine: A new implementation of BioWare's Aurora engine.")
set(CPACK_PACKAGE_VENDOR "Xoreos Project")

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

If it doesn't stand out too much, I'd rather like "xoreos" to always be all-lowercase. The only place were we don't do that is the Mac Bundle name thing, because I've been told it looks bad otherwise.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

If it doesn't stand out too much, I'd rather like "xoreos" to always be all-lowercase. The only place were we don't do that is the Mac Bundle name thing, because I've been told it looks bad otherwise.

Show outdated Hide outdated CMakeLists.txt
find_program(DPKG_CMD dpkg)
if(DPKG_CMD)
list(APPEND CPACK_GENERATOR "DEB")
set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6, libgcc1, libz1, libboost-all-dev, libsdl1.2-dev, libopenal1, libgl1, libfreetype6, libglew1.7, libmad0, libfaad2, libvorbis0a, libxvidcore4")

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

Make that libsdl2-dev instead of libsdl1.2-dev

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

Make that libsdl2-dev instead of libsdl1.2-dev

# -------------------------------------------------------------------------
# find the required libraries

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

You're missing liblzma, which is used for BZF archives (which are found in the iOS version of KotOR)

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

You're missing liblzma, which is used for BZF archives (which are found in the iOS version of KotOR)

else()
add_definitions(-DXOREOS_LITTLE_ENDIAN=1)
endif()

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

I don't suppose there's a way to define XOREOS_REV, XOREOS_REVDESC and XOREOS_BUILDDATE (the gitstamp / common/Makefile.am hackery)? Those need to trigger a recompile for version.o on git changes, after all...

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

I don't suppose there's a way to define XOREOS_REV, XOREOS_REVDESC and XOREOS_BUILDDATE (the gitstamp / common/Makefile.am hackery)? Those need to trigger a recompile for version.o on git changes, after all...

This comment has been minimized.

@berenm

berenm Apr 20, 2015

Contributor

Should be doable, I'll have a look.

@berenm

berenm Apr 20, 2015

Contributor

Should be doable, I'll have a look.

Show outdated Hide outdated CMakeLists.txt
include_directories(${ZLIB_INCLUDE_DIRS})
list(APPEND XOREOS_LIBRARIES ${ZLIB_LIBRARIES})
find_package(Boost COMPONENTS filesystem system regex date_time REQUIRED)

This comment has been minimized.

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

You're missing boost.atomic there. (I take it the components are only for non-header-only libraries?)

@DrMcCoy

DrMcCoy Apr 20, 2015

Member

You're missing boost.atomic there. (I take it the components are only for non-header-only libraries?)

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 20, 2015

Member

Okay, since this seems to be the only way to support MSVC and stop turning MSVC-only people away, I'm considering accepting this change as a kind of unsupported, alternative "use this if you absolutely have to, but don't yell at us if it's not working" kind of thing.

And you, @berenm, will have to keep it up-to-date with library dependency and config.h changes. I don't expect those to come often, of course. Nor do I expect to complicate our Makefile.am files, so those should keep being easily parseable, I guess.

Member

DrMcCoy commented Apr 20, 2015

Okay, since this seems to be the only way to support MSVC and stop turning MSVC-only people away, I'm considering accepting this change as a kind of unsupported, alternative "use this if you absolutely have to, but don't yell at us if it's not working" kind of thing.

And you, @berenm, will have to keep it up-to-date with library dependency and config.h changes. I don't expect those to come often, of course. Nor do I expect to complicate our Makefile.am files, so those should keep being easily parseable, I guess.

@berenm

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Apr 20, 2015

Contributor

Sounds perfectly fine, please assign any related issue to me and I will take care of it.

Contributor

berenm commented Apr 20, 2015

Sounds perfectly fine, please assign any related issue to me and I will take care of it.

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 20, 2015

Member

Okay, thanks. :)

To recap, please change these things:

  • remove that .gitignore changeset
  • add checks for liblzma and boost.atomic
  • never use the system's Lua library
  • either remove the packaging or change the mail contact and libsdl1.2-dev to libsdl2-dev
  • change "Xoreos" to all-lower "xoreos" where appropriate

Nice to haves:

  • the gitstamp and date/time defines
Member

DrMcCoy commented Apr 20, 2015

Okay, thanks. :)

To recap, please change these things:

  • remove that .gitignore changeset
  • add checks for liblzma and boost.atomic
  • never use the system's Lua library
  • either remove the packaging or change the mail contact and libsdl1.2-dev to libsdl2-dev
  • change "Xoreos" to all-lower "xoreos" where appropriate

Nice to haves:

  • the gitstamp and date/time defines
@berenm

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Apr 20, 2015

Contributor

Alright, I did the changes.

I removed packaging stuff, as there was no CMake install directives to install things into the target tree, so the packages were empty. It can be added back later on, if needed.

Git version string and build date are now passed as preprocessor definition when compiling src/common/version.cpp, but the dirty flag is not 100% accurate. For some reason, when using Makefiles, make feels that it has to rebuild the whole common library's sources although the preproc macros are for version.cpp only... When using ninja, everything works as expected. 😐

I also replaced the cmake 3.0 specific syntax, so it works with cmake 2.8.12.

Contributor

berenm commented Apr 20, 2015

Alright, I did the changes.

I removed packaging stuff, as there was no CMake install directives to install things into the target tree, so the packages were empty. It can be added back later on, if needed.

Git version string and build date are now passed as preprocessor definition when compiling src/common/version.cpp, but the dirty flag is not 100% accurate. For some reason, when using Makefiles, make feels that it has to rebuild the whole common library's sources although the preproc macros are for version.cpp only... When using ninja, everything works as expected. 😐

I also replaced the cmake 3.0 specific syntax, so it works with cmake 2.8.12.

BUILD: Add scripts to parse all Makefile.am and build with CMake.
CMake itself parses the configure.ac file to get the list of Makefile.am, and
parses each Makefile to get the libraries/binaries and their sources and link
dependencies.

The target are registered in CMake and it can be used to generate whatever
CMake can generate.

No change is required regarding autotools, and as long as the Makefile.am files
stay as simple as they are, the CMake script that parses them should handle any
source addition/removal.

There's still duplication in term of library checks and platform flags, which
might be more difficult to replace, but this is probably not going to change
that often.
@berenm

This comment has been minimized.

Show comment
Hide comment
@berenm

berenm Apr 20, 2015

Contributor

XOREOS_REV was not set to the right portion of XOREOS_REVDESC, it's fixed now.

Contributor

berenm commented Apr 20, 2015

XOREOS_REV was not set to the right portion of XOREOS_REVDESC, it's fixed now.

@DrMcCoy

This comment has been minimized.

Show comment
Hide comment
@DrMcCoy

DrMcCoy Apr 20, 2015

Member

Okay, merged it. Thanks!

Member

DrMcCoy commented Apr 20, 2015

Okay, merged it. Thanks!

@DrMcCoy DrMcCoy closed this Apr 20, 2015

@berenm berenm deleted the berenm:feature/cmake branch Apr 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment