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 77.9% 77.9% -0.0%
=========================================
Files 782 781 -1
Lines 66616 66618 +2
Branches 8161 8127 -34
=========================================
- Hits 51902 51896 -6
- Misses 14714 14722 +8
... and 7 files with indirect coverage changes |
|
Not a review yet, but this is such a cool idea. |
cmake/RippledCore.cmake
Outdated
| 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?
There was a problem hiding this comment.
Perhaps comment out and put a comment above, to explain why this is not necessary and in what condition it might become necessary again ?
|
I like how you moved Given we already specialize both |
|
I do wonder whether |
|
|
Makes sense. All the more reason to make an effort moving parts of |
|
Bad news right out the gate on Windows builds: |
|
@ximinez ok, try again. |
|
It's building successfully now. Neat workaround. Super annoying that this is an issue, though. I remember there were some Otherwise, I'll come back to the rest of this review as soon as I get some other priorities knocked out. |
| # add_module(parent a) | ||
| # add_module(parent b) | ||
| # target_link_libraries(project.libparent.b PUBLIC project.libparent.a) | ||
| function(add_module parent name) |
There was a problem hiding this comment.
Wouldn't it be even nicer if you could optionally pass the libraries to link the target with right here too? Is it possible to add the PUBLIC lib1 lib2 through args somehow?
There was a problem hiding this comment.
I find the current call pattern nice enough. It reads like conventional CMake to me. If someone wants to add the function you're talking about, I think that's fine, but I'd rather keep this function just doing the one thing.
|
@thejohnfreeman I see this has two approvals. Since I've verified that it builds under Windows, it's up to you if you want to wait for mine, too, or go ahead and add the "Passed" label and provide a commit message. I'll preemptively mark it as "Blocked" now to be sure we wait until after the 2.3.0 release before merging. |
|
@ximinez I would still appreciate your review. |
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