-
Notifications
You must be signed in to change notification settings - Fork 117
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
Use target_link_options to pass linker options #108
base: master
Are you sure you want to change the base?
Conversation
Thank you for the PR. However, I would not call this a "spell error". You are replacing one command (target_link_libraries) with another command (target_link_options). This command did not exist before in cmake, it only entered the language in version 3.13 (see https://cmake.org/cmake/help/latest/command/target_link_options.html). Now, you are right that the new command is semantically the "right" one, now that they finally decided to differentiate it from the former command. However, both commands do the same thing in the end, and if we want to use the new command, we have to raise the minimum version requirement to 3.13 from 3.0, which it is at now. We should discuss if we want to do this for a change that does not have any functional improvement. @hbwang15: Please raise the mimimum cmake version in the main CMakeLists.txt and add that to the PR. Everyone: What's your opinion about this change? |
Sorry for my limit knowledge on cmake , I just misunderstand about the command {target_link_libraries} as use for adding link options, As cmake already give more clear command, that is {target_link_options}, so i strongy suggest to upgrade cmake-init to make it more clear for users. |
I'm, too, thinking about our minimum required CMake versions from time to time and for me it depends on the available CMake versions for our target platforms, the availability of fallbacks for modern features/interfaces, and the severity if missing features if a platform does not yet support a more current version. Following my checklist we would have:
However, I'm still undecided and suggest to investigate / clarify the following issues:
Summarizing, I'm glad that this interface exists in modern CMake but I'm not sure how it should influence this project as our template works completely fine with CMake 3.0. |
Can we provide an own implementation of |
Somehow, this seems to be an implementation to #103. |
some spell errors found when i use cmake-init, see the differences below