Dedicated Third Party Targets in Project Tree #132
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is open to discussion. The ideas and motivation are as follows:
(1) There is a lot of legacy third party code "hiding" down the project tree of ETISS, e.g., pugixml
(2) Some third party code is fetched and built in CMakeLists.txt which makes it hard to maintain, e.g., the external softfloat in the JIT library libsoftfloat
(3) Current approach, for ELFIO and SimpleIni, does fetch(+build) in the top level CMakeLists.txt, which bloats the top level CMake description (but is IMO better than (1) and (2).
Introducing a dedicated third party node in the project source tree could help establish a "how to integrate" foreign code. My proposed solution works for CMake-FetchContent, CMake-ExternalProject, and Git-Submodules, should we ever decide to use those instead. The core idea is to establish CMake targets in the new
third_party
node that are added before e.g. thesrc
directory is added. This should make those targets available to multiple targets - be it ETISS, Arch or JIT.