Open weitjong opened 8 years ago
While doing this, might as well as take the opportunity to deprecate the usage of our custom define_dependency_libs() macro. When configured correctly, CMake should be able to handle library dependency transitively as needed instead of managing this by ourselves as per currently and in doing so, has actually caused a few quirks (non idiomatic usage) in our CMake build scripts.
[Done] Below is one of the example of non idiomatic usage of manual library dependency management. https://github.com/urho3d/Urho3D/blob/6e0a447ebbdd9b253653f125a6ebc623b46a9478/CMake/Modules/FindUrho3D.cmake#L258 I believe there should be a better way to let CMake manages this library dependency and free the burden from the devs to have to remember and manage those dependencies.
[Won't fix - on the second thought this is not a good idea because of build dependency] While doing this, if possible also enhance the create_symlink() to configure a fallback custom command (in case symlink and mklink is not possible) to redo the file copying regardless. That is, when a natural target is not available then "park" the custom command to Urho3D library target or something like that.
[Done] Also may as well attempt to support Debian multi-arch properly. We should not have hard-coded the target triplet when trying to find the library. See https://github.com/urho3d/Urho3D/blob/3b4b354d51dbe084cc44714f1e6fa822771702e9/CMake/Modules/FindMir.cmake#L33-L37
[Done] Also fix a bug in the setup_executable() macro where it may wrongly replace EXE linker flags with NODEPS version without honoring the EXE linker flags configured by CMake toolchain file. See https://github.com/urho3d/Urho3D/blob/20da34f21b44671d87f7eab4389a049db7a04c6b/CMake/Modules/Urho3D-CMake-common.cmake#L1161-L1163 This may cause problem for Android executable target as it loses '-pie' linker flag, which is crucial when targeting API platform android-16 and above.
[Done] If possible, make the install_header_files()
macro to clean up after itself when switching between directory and file modes. See #1499 for the issue it might potentially cause.
Marking this stale since there has been no activity for 30 days. It will be closed if there is no activity for another 15 days.
Currently the generated Urho3D.pc file is not entirely correct. There are at least two things we could improve.