Starling third party fix #65
Conversation
RReichert
force-pushed
the
rodrigor/starling-third-party-fix
branch
from
f861c13 to
fc47377
Compare
woodfell
left a comment
woodfell
left a comment
There was a problem hiding this comment.
One request to fix faulty search paths, other than that looks good
GenericFindDependency.cmake
Outdated
| else() | ||
| list(APPEND x_SOURCE_SEARCH_PATHS "${CMAKE_CURRENT_SOURCE_DIR}/${x_SOURCE_DIR}") | ||
| list(APPEND x_SOURCE_SEARCH_PATHS "${CMAKE_CURRENT_SOURCE_DIR}/third_party/${x_SOURCE_DIR}") | ||
| list(APPEND x_SOURCE_SEARCH_PATHS "${PROJECT_SOURCE_DIR}/${x_SOURCE_DIR}") |
There was a problem hiding this comment.
I think the real issue here is that this line shouldn't be here, neither should the one 2 lines above. A long time ago we agreed that all submodules will live under third_party, these modules shouldn't be searching any part that doesn't have third_party in it
There was a problem hiding this comment.
Seems like a good idea to remove the old system. I've since rolled back the changes and used the suggested approach.
RReichert
force-pushed
the
rodrigor/starling-third-party-fix
branch
from
645b78f to
c9225eb
Compare
| GenericFindDependency( | ||
| TARGET protobuf-nanopb | ||
| SOURCE_DIR "third_party/nanopb" | ||
| SOURCE_DIR "nanopb" |
There was a problem hiding this comment.
this was needed to be updated since one of the deleted paths was working with the original third_party/nanopd.
|
NOTE these changes are currently being used by the https://github.com/swift-nav/swiftlets/pull/880 PR. |
Background
There were two issues during the restructuring of our code base.
The first change that needed to be done was fix the
create_source_search_pathsfunction. After adding thestarlingfolder in the root directory,FindStarling.cmakescript's usage ofSOURCE_DIRmeant that the${CMAKE_CURRENT_SOURCE_DIR}/${x_SOURCE_DIR}folder was choose as the folder for which it would calladd_subdirectoryon to introduce the starling repo's cmake targets.The second issue was simply that some starling libraries weren't being flagged as exportable by the subdirectory, which meant that if we were to use
-DTHIRD_PARTY_INCLUDES_AS_SYSTEM=falsecmake cache variable, it would fail static analysis asclang-tidywould complain about eigen values.