-
-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make corrosion_install work for library files and update docs #543
Conversation
Works on corrosion-rs#415. This only installs the actual library file(s) and not extras such as headers. Not tested on Windows for compatibility with import library files for shared libraries.
Works on corrosion-rs#63. The function definition is currently prescriptive, since it describes features that don't currently work. EXPORT causes a FATAL_ERROR, and PRIVATE_HEADER/PUBLIC_HEADER do nothing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this, and especially for also adding documentation!
[CONFIGURATIONS [Debug|Release|<other-configuration>]] | ||
] [...]) | ||
``` | ||
* **TARGETS**: Target or targets to install. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should clarify here that the targets must have been targets added by corrosion. Perhaps something like:
Rust library or executable targets imported by corrosion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, but I'm not certain, that we'll need to accept all target kinds, since if the users want to create C++ bindings as well they will need to create a new target that depends on the rust lib target. Then in install(TARGETS rust-lib cpp-bindings EXPORT MyProjectTargets)
we need to list all targets and their dependents, otherwise it will error.
endif() | ||
|
||
install( | ||
IMPORTED_RUNTIME_ARTIFACTS ${INSTALL_TARGET}-shared |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know I'm the one that suggested looking into IMPORTED_RUNTIME_ARTIFACTS
, but after reading the documentation again, I'm thinking that the usecase is meant to install an IMPORTED executable along with all the dynamic libraries it depends on.
I guess there could be Rust shared libraries, which depend on other shared libraries, so having CMake automatically also install those would be helpful. But I'm not sure if that would actually work as I'm expecting now, so I think we probably really need to test this out in an example project.
Have you tested the shared library install locally and can confirm it works in practice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tested the shared library install locally and can confirm it works in practice?
Yes, I have tested it on Linux.
Inside the is_odd
directory of my example repository I run
cmake -B build -S . -G Ninja && cmake --build build && cmake --install build --prefix /tmp/install
and it outputs
-- Install configuration: ""
-- Installing: /tmp/install/lib/libis_odd.a
-- Installing: /tmp/install/lib/libis_odd.so
I guess there could be Rust shared libraries, which depend on other shared libraries, so having CMake automatically also install those would be helpful.
I am unsure if this also installs Windows .lib
files, but I know for sure that the manual approach doesn't, so I preferred this way.
Changes requested in corrosion-rs#543.
Not sure if I have broken the MacOS tests, but it seems unrelated. |
The test failures on macos are unrelated to this PR. |
@jschwe Do you need anything else from me on this PR? |
Co-authored-by: Tobias Fella <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is still one todo in the documentation that should be addressed before merging. Otherwise, looks fine for an initial implementation. Lets see how it works in practice.
If I have some time next week, I'll try to add a test.
Fixed.
Cool. The https://github.com/gtker/corrosion_export repo can be used with the functionality that is now done in |
Works on #415 and #63.
This only installs the actual library file(s) and not extras such as headers.
Not tested on Windows for compatibility with import library files for shared libraries.
I moved the function definition out to be used as an anchor so it could be used for docs without modifying it, since I'm not entirely sure what the planned feature set of it is going to be.