Modding, Mission Design, and Coding > Cross-Platform Development
Anybody interested in CMake? (I'm new to the forum)
The E:
I would also recommend you join the #scp IRC channel on esper.net, it's where we coders hang out.
m!m:
I am currently trying to get my CMake setup to work on Mac but I have no direct access to that OS. Do you have access to a Mac machine? If that's the case, could you try to generate project files from my branch? I am currently doing some iterative Mac development with chief1983, which is a bit slow so someone with CMake experience and a Mac would speed that process up immensely.
MasterGeek:
--- Quote from: AdmiralRalwood on June 12, 2015, 01:00:53 am ---Unfortunately, the forum search is flat-out broken. You get better results if you use google with "site:hard-light.net".
--- Quote from: MasterGeek on June 11, 2015, 10:41:46 pm ---I've done a lot of threading work in the past, and have a pretty good understanding of concurrency and related topics.
--- End quote ---
Making FSO multithreaded would basically require rewriting the whole thing. I mean, if you want to do that, I won't stop you, but that's pretty much the major reason it hasn't been done already (at some point it was attempted to just multithread the collision detection, but the added overhead from making only that be multithreaded basically removed any performance gains).
--- Quote from: MasterGeek on June 11, 2015, 10:41:46 pm ---Consequently, I'm pretty good when it comes to networking
--- End quote ---
That could be useful; the netcode is in need of an overhaul.
--- Quote from: MasterGeek on June 11, 2015, 10:41:46 pm ---how about that in-game config system that I've read people dreaming about occasionaly on this forum (the one that's supposed to handle most of the options that are currently command line options)? Is there much work done on that?
--- End quote ---
AFAIK no work has been done on that.
--- End quote ---
In regards to threading: have you checked out std::thread and std::async? C++11 added a lot of good stuff. Sounds like a big project, though. I think I'll pass for now.
In regards to networking: sounds interesting. What needs to be reworked?
--- Quote from: m!m on June 12, 2015, 03:19:35 am ---I am currently trying to get my CMake setup to work on Mac but I have no direct access to that OS. Do you have access to a Mac machine? If that's the case, could you try to generate project files from my branch? I am currently doing some iterative Mac development with chief1983, which is a bit slow so someone with CMake experience and a Mac would speed that process up immensely.
--- End quote ---
I'll see if I can build it. I can't test it though, since the mac in question is at work, and it's the weekend. I'll be working over SSH.
MasterGeek:
Well, after a bit of hacking I got the thing building on mac. Most of the problems were related to how dependencies were found/handled/etc.
First of all, the 'code' target wasn't getting linked against OpenAL and OpenGL when it got built (and was missing the header includes as well). I fixed that in code/CMakeLists.txt.
Then, since OpenAL is a dynamic library on mac, it needs to be re-linked against the 'Freespace2' so code.a can get its symbols, so I fixed that in freespace2/CMakeLists.txt.
Then comes the oggvorbis crap. :banghead: I don't know where those binaries in lib/mac came from, but my linker said they were for an invalid format/architecture, and refused to use them. Since I don't believe in keeping binaries in a source tree, I deleted the entire lib/mac directory, and told lib/oggvorbis/CMakeLists.txt to pull the libraries and the headers from an external source (I just installed the libraries with Mac Brew). I should warn that lib/oggvorbis/CMakeLists.txt may not complain if it can't find the libs since I did it quick and dirty, so some code should probably be added there to check for that. I may split it off into its own find module, since that's how it's supposed to be done in CMake.
The way OpenAL was being imported before was causing weirdness. OpenAL is a framework, but after all the special processing lib/openal/CMakeLists.txt was doing to the import paths, by the time it got the the linker it wasn't specified as a framework but the framework's directory was passed as if it were a library file! Anyway, I made an exception that just bypasses lib/openal/CMakeLists.txt when on a mac and OpenAL gets imported the normal find_package way in code/CMakeLists.txt and freespace2/CMakeLists.txt... Honestly, simple find_package commands should replace all the complicated CMakeLists.txt in the lib directory for all operating systems. I don't think there's any need to keep dependencies in the source tree when CMake can handle them so well otherwise. If dependencies get managed manually in the CMakeLists.txt, then half the purpose of CMake is defeated.
Anyway, here are my changes: https://github.com/fjelliott/fs2open/tree/cmake-mac.
If you're looking for a diff: https://github.com/fjelliott/fs2open/compare/cmake...fjelliott:cmake-mac
m!m:
--- Quote from: MasterGeek on June 12, 2015, 06:44:27 pm ---In regards to threading: have you checked out std::thread and std::async? C++11 added a lot of good stuff. Sounds like a big project, though. I think I'll pass for now.
--- End quote ---
Our specific problem is that most of the code uses global variables which means it's hard or impossible to multi-thread.
--- Quote from: MasterGeek on June 12, 2015, 11:43:07 pm ---Well, after a bit of hacking I got the thing building on mac. Most of the problems were related to how dependencies were found/handled/etc.
First of all, the 'code' target wasn't getting linked against OpenAL and OpenGL when it got built (and was missing the header includes as well). I fixed that in code/CMakeLists.txt.
Then, since OpenAL is a dynamic library on mac, it needs to be re-linked against the 'Freespace2' so code.a can get its symbols, so I fixed that in freespace2/CMakeLists.txt.
Then comes the oggvorbis crap. :banghead: I don't know where those binaries in lib/mac came from, but my linker said they were for an invalid format/architecture, and refused to use them. Since I don't believe in keeping binaries in a source tree, I deleted the entire lib/mac directory, and told lib/oggvorbis/CMakeLists.txt to pull the libraries and the headers from an external source (I just installed the libraries with Mac Brew). I should warn that lib/oggvorbis/CMakeLists.txt may not complain if it can't find the libs since I did it quick and dirty, so some code should probably be added there to check for that. I may split it off into its own find module, since that's how it's supposed to be done in CMake.
--- End quote ---
I really don't like using the find_* functions anywhere but in the lib directory as that makes the code very hard to understand. Most of those commands only supply variables and no interface target which are easier to use IMO. I used the changes in your branch to do some fixes in my branch (although that broke the linux builds, I'll have to fix those). Given that we have different handling for the platforms a find module dedicated to mac doesn't make much sense to me.
--- Quote from: MasterGeek on June 12, 2015, 11:43:07 pm ---The way OpenAL was being imported before was causing weirdness. OpenAL is a framework, but after all the special processing lib/openal/CMakeLists.txt was doing to the import paths, by the time it got the the linker it wasn't specified as a framework but the framework's directory was passed as if it were a library file! Anyway, I made an exception that just bypasses lib/openal/CMakeLists.txt when on a mac and OpenAL gets imported the normal find_package way in code/CMakeLists.txt and freespace2/CMakeLists.txt... Honestly, simple find_package commands should replace all the complicated CMakeLists.txt in the lib directory for all operating systems. I don't think there's any need to keep dependencies in the source tree when CMake can handle them so well otherwise. If dependencies get managed manually in the CMakeLists.txt, then half the purpose of CMake is defeated.
--- End quote ---
I changed the ADD_IMPORTED_LIB macro to use an interface target which should replicate what you have done in code/CMakeLists.txt (I did the same for OpenGL). The problem with find_package is that we supply prebuilt binaries for Windows (at some point I want to move those into a separate submodule) so that would need to be handled as a special case. I also like using pkg-config on linux as that handles the different platforms much better than a custom find module.
Did you have problems with SDL? We had issues getting that linked into the project as XCode was doing something weird.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version