-
Notifications
You must be signed in to change notification settings - Fork 61
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
Transition build system to CMake #1288
base: Orbiter2016
Are you sure you want to change the base?
Conversation
target_link_libraries(${PROJECT_NAME} Orbiter) | ||
target_link_libraries(${PROJECT_NAME} Orbitersdk) | ||
target_link_libraries(${PROJECT_NAME} PanelSDK) | ||
target_link_libraries(${PROJECT_NAME} XRSound) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why you're only passing one library to each target_link_libraries()
call? You could instead do something like
target_link_libraries(${PROJECT_NAME} PRIVATE
GLU32
dxguid
dinput8
OpenGL32
User32
WinMM
WS2_32
Orbiter
Orbitersdk
PanelSDK
XRSound
)
which would be less verbose and potentionally a bit more performant on the CMake side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, I didn't realize that was possible, thanks! Much more elegant.
I'm aiming for seamless cross-compatibility between Orbiter Beta R90 and OpenOrbiter, let's see if it's possible!
Everything is compiling successfully!
This should hopefully be all sane defaults, which we won't change unless we have to.
This should avoid myself (or other people) from accidentally committing situational config options based on their personal installations of NASSP/Orbiter.
I believe that NASSP would gain significant benefits from transitioning our build system to use CMake. In a nutshell, CMake is a higher-level, more abstract system than something like the Visual Studio project files that we currently use to define our vessels, libraries, MFDs, etc. Rather than directly instructing a C++ compiler on how to build the code, it processes a set of instructions like a script, and generates an intermediary output file which is then used by a C++ compiler to build our code. (In theory, CMake can actually be used to generate VS project files, which is pretty cool.)
CMake has some very nice features for those familiar with it, but it will also let us keep our existing workflow relatively unchanged. Some particular benefits I see for NASSP are as follows:
Since these changes would inherently allow for OpenOrbiter compatibility, this PR supersedes #793.
I have had several devs personally encourage these changes, and I am naturally an advocate for switching to CMake after seeing the workflow and practical improvements it offers us. As-is, the only changes needed to put this in a fully "ready for prime-time" state would be to delete the old VS project files, to ensure users don't get confused and use the wrong system. I have not done this yet, for the sake of making it easy to merge/rebase to upstream changes or for folks to experiment with migrating their outstanding pull requests if they so desire. These are foundational changes, and I want to give everybody plenty of time to figure out what this is all about, and to test and give me feedback on workflow, stability, and other issues that I can't discover by myself. I have only been using and learning about CMake for a year or two, and this is by far the most complex thing I've done with it. Nevertheless, I have been very encouraged by how simple it has been to re-organize a project as big and complex as NASSP into this new build system with relatively little work; I think it speaks to CMake's strengths that it can be done by even someone as relatively inexperienced as me.
Regarding outstanding PRs: any other pull requests or alternate branches in progress that require modification of the VS project files will need corresponding modifications made to the CMake project files in order to work. That is to say, if you added or deleted a source code file in some custom branch of NASSP, you'll need to add or delete that file in the appropriate vessel's CMakeLists.txt in order to incorporate those changes into this new CMake-ified setup. I'd personally recommend getting familiar with the basic workflow of building NASSP like this first, and then move up to porting your PRs or branches to this new system. And please let me know (preferably on Discord) what challenges you face or questions you have.
Until we progress towards actually merging this, I will be rebasing and force-pushing this branch periodically to bring it up-to-date with upstream changes in a way that doesn't cause merge commits, for cleanliness' sake. BE AWARE that if you make a fork of this branch or clone it, the remote branch can (and will) spontaneously disconnect from your local change history, even if you don't make any personal changes. This will probably break things on your end and require you to reset the branch.
To do this, I recommend the following steps (this will discard any custom changes you've made):
git reset --hard HEAD~50
(Resets the changes back by 50 commits, to get us back to a state before any CMake-related changes)git pull
(Pulls the changes from the remote branch, which will have the latest upstream changes, with the CMake-related commits always at the very top of the list)Please DO test this branch out! But until we know this is actually in a good place to be merged, please DON'T do any work with it that you aren't willing to potentially re-do.