libgeos
CMake: remove the new `PROJECT_IS_TOP_LEVEL` logic
https://github.com/libgeos/geos/pull/518 unconditionally prevents to build few things like geosop when wrapped by another CMakeLists. Could you revert this logic please? It's quite annoying for conan package manager. The main issue for an add_subdirectory() of geos in previous logic was MakeDistCheck (and few CMAKE_SOURCE_DIR/CMAKE_BINARY_DIR to replace in benchmarks branch) , otherwise it was working fine.
@SpaceIm can you explain what the specific issue(s) it is causing for Conan? If it's a case of adding geosop back then I'm fine with it, but are there other issues? (I'm not familiar with Conan's build system)
I can offer a bit of help too. There is a real need to allow CMake projects to be made into subprojects. PROJ is another example that I'm aware of that has this ability, although with a different approach, and I can see the current build here. Question to @SpaceIm, are there any issues with PROJ's CMake setup?
@SpaceIm can you explain what the specific issue(s) it is causing for Conan? If it's a case of adding geosop back then I'm fine with it, but are there other issues? (I'm not familiar with Conan's build system)
It's not specific to conan, but yes the main issue is that geosop is not built anymore. The idea would be to just disable MakeDistCheck if PROJECT_IS_TOP_LEVEL is False, since it was the only issue with add_subdirectory(). All other logic based on PROJECT_IS_TOP_LEVEL can be removed I think.
Question to @SpaceIm, are there any issues with PROJ's CMake setup?
No issue in PROJ related to add_subdirectory().
since it was the only issue with add_subdirectory(). All other logic based on PROJECT_IS_TOP_LEVEL can be removed I think.
No, CMAKE_SOURCE_DIR/CMAKE_BINARY_DIR are real problems when using GEOS as a subproject, as is polluting the parent's ctest, and having alias targets that match find_package()...
So I'm guessing Conan's GEOS packaging just makes a super-project specifically for GEOS that then wraps the geos via add_subdirectory()? Is this the "new" Conan CMake integration, the "old" one, or both?
since it was the only issue with add_subdirectory(). All other logic based on PROJECT_IS_TOP_LEVEL can be removed I think.
No, CMAKE_SOURCE_DIR/CMAKE_BINARY_DIR are real problems when using GEOS as a subproject, as is polluting the parent's ctest, and having alias targets that match find_package()...
I see. And a simple replacement of CMAKE_SOURCE_DIR/CMAKE_BINARY_DIR by CMAKE_CURRENT_SOURCE_DIR/CMAKE_CURRENT_BINARY_DIR (or PROJECT_SOURCE_DIR/PROJECT_BINARY_DIR depending on the logic)?
So I'm guessing Conan's GEOS packaging just makes a super-project specifically for GEOS that then wraps the geos via add_subdirectory()? Is this the "new" Conan CMake integration, the "old" one, or both?
It's true that it doesn't really matter with the new conan cmake integration (relying on a toolchain & presets), and actually I've migrated geos recipe to this new integration few days ago.
FTR, the per-project equivalent of CMAKE_SOURCE_DIR/CMAKE_BINARY_DIR is <PROJECT-NAME>_SOURCE_DIR/<PROJECT-NAME>_BINARY_DIR.
