BUILD: Add scripts to parse all Makefile.am and build with CMake.#57
BUILD: Add scripts to parse all Makefile.am and build with CMake.#57berenm wants to merge 1 commit into
Conversation
|
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? |
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 :/
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. |
This is a syntax introduced in CMake 3.0.0, it was to avoid too much quote escaping in the strings.
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.
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 :). |
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)
|
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. |
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. :/ |
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. |
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. |
|
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... |
|
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?) |
Yes, for NWN2, that's about it. You can open a debug console with Ctrl+D, though, and load other areas and modules.
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. |
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.
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. |
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. |
There was a problem hiding this comment.
This changeset doesn't belong here.
|
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. |
|
Sounds perfectly fine, please assign any related issue to me and I will take care of it. |
|
Okay, thanks. :) To recap, please change these things:
Nice to haves:
|
|
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 I also replaced the cmake 3.0 specific syntax, so it works with cmake 2.8.12. |
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.
|
XOREOS_REV was not set to the right portion of XOREOS_REVDESC, it's fixed now. |
|
Okay, merged it. Thanks! |
4 participants
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.