Enforce levelization in libxrpl with CMake #5111
Conversation
Define each "module" of libxrpl as a separate OBJECT library in CMake. Link each one only to modules of a lower level. Then link all of them into libxrpl itself.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #5111 +/- ##
=========================================
- Coverage 76.2% 75.4% -0.8%
=========================================
Files 760 666 -94
Lines 61550 58420 -3130
Branches 8123 7982 -141
=========================================
- Hits 46884 44061 -2823
+ Misses 14666 14359 -307
... and 99 files with indirect coverage changes |
|
Not a review yet, but this is such a cool idea. |
cmake/isolate_headers.cmake
Outdated
| # isolate_headers(target A B scope) | ||
| function(isolate_headers target A B scope) | ||
| file(RELATIVE_PATH C "${A}" "${B}") | ||
| set(X "${CMAKE_CURRENT_BINARY_DIR}/include/${target}") |
There was a problem hiding this comment.
I think /include/ is misleading here. It's source file isolation feature, not includes.
There was a problem hiding this comment.
I suggest
- set(X "${CMAKE_CURRENT_BINARY_DIR}/include/${target}")
+ set(X "${CMAKE_CURRENT_BINARY_DIR}/modules/${target}")
| isolate_headers( | ||
| ${target} | ||
| "${CMAKE_CURRENT_SOURCE_DIR}/src" | ||
| "${CMAKE_CURRENT_SOURCE_DIR}/src/lib${parent}/${name}" | ||
| PRIVATE | ||
| ) |
There was a problem hiding this comment.
I think this is not needed ? Or my misunderstanding of how CMake works just showed :-D
There was a problem hiding this comment.
It's in case a module has private headers, not installed, but included by other translation units. I don't know if any of our modules have these (yet), but I'm copying this implementation from my more generalized project.
| PRIVATE | ||
| $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src> |
There was a problem hiding this comment.
I think this is probably not needed ?
There was a problem hiding this comment.
actually, upon some testing, this whole target_include_directories seem to be not needed.
There was a problem hiding this comment.
It's not needed now that all of the subdirectories in libxrpl are modules. It was necessary as I migrated them one-by-one, and it could be necessary in the future if someone adds a non-module subdirectory. Could be nice if it "just works" without tampering with the CMake. What do you think?
|
I like how you moved Given we already specialize both |
Adds two CMake functions:
add_module(library subdirectory): Declares anOBJECT"library" (a CMake abstraction for a collection of object files) with sources from the given subdirectory of the given library, representing a module. Isolates the module's headers by creating a subdirectory in the build directory, e.g..build/tmp123, that contains just a symlink, e.g..build/tmp123/basics, to the module's header directory,e.g. include/xrpl/basics, in the source directory, and putting.build/tmp123(but notinclude/xrpl) on the include path of the module sources. This prevents the module sources from including headers not explicitly linked to the module in CMake withtarget_link_libraries.target_link_modules(library scope modules...): Links the library target to each of the module targets, and removes their sources from its source list (so they are not compiled and linked twice).Uses these functions to separate and explicitly link modules in libxrpl:
beastbasicsjson,cryptoprotocolresource,server