I was fightning with strange errors in my code. Until I've noticed that the project-related variables I'm relying upon for various tasks in my own CMakeLists.txt were all referring to Magic Leap SDK-related things. How could this be?
Well, it turns out that the find package module file ENV{MLSDK}/<version>/cmake/FindMagicLeap.cmake (not to be confused with the root find package module file ENV{MLSDK}/cmake/FindMagicLeap.cmake) sets project(ML). At least for Magic Leap SDK v1.5.0 and v1.6.0.
Is this something wanted/expected? Not from my point of view: CMake find package module/config files shouldn't alter a consumer's project, but opinions may vary
I have no problem finding and/or using MLSDK. However, since FindMagicLeap.cmake is calling project(ML), all the project-related CMake variables of a client application are now overwritten by Magic Leap's one. That means for example that PROJECT_NAME or PROJECT_VERSION are no more the ones that you've set for your application (e.g. project(MyApp 0.3)), but the ones set by MLSDK, i.e.ML for PROJECT_NAME and nothing BTW for PROJECT_VERSION. This is more problematic for a everything's path-related: PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR for example no more refer to your project's source file and binary directories. This blog (Project Variables section) nicely explains how CMake project variables are impacted. Using the CMAKE_PROJECT_* variables isn't an option on my side, as I'm developing a middleware library (partly leveraging MLSDK), used by a client application. So CMAKE_PROJECT_* refer to the client application.
Thank you for the explanation and sorry for the slower reply. I was verifying with one of our internal teams about the expected behavior. I have created a bug ticket based on your report. Thank you for letting us know !
