Skip to content
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

corrosion_install: fix reconfiguring breaking EXPORTs #555

Merged
merged 3 commits into from
Sep 3, 2024

Conversation

gtker
Copy link
Contributor

@gtker gtker commented Sep 2, 2024

Sorry for the immediate do over, but it seems there were a few mistakes in my last PR #544.

It seems the else was accidentally put on the check for a TARGET ${TARGET_NAME}-static lib instead of the TARGET_TYPE STREQUAL *.

Additionally, I forgot to put a guard on the file(APPEND) statements, so every reconfigure would add yet another set of add_librarys for both static/shared, leading to it not working.

I'm not sure what the correct solution for this is, but the current solution at the very least works.

@@ -1308,19 +1308,21 @@ function(corrosion_install)

if(EXPORT_NAME)
get_target_property(COR_FILE_NAME ${INSTALL_TARGET}-static COR_FILE_NAME)
file(APPEND
${CMAKE_BINARY_DIR}/corrosion/${EXTRA_TARGETS_EXPORT_NAME}
if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/corrosion/${EXTRA_TARGETS_EXPORT_NAME}-static-exists)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we assume that corrosion_install() will only be called once per target? If yes perhaps we could delete the file first.
We would still want to overwrite the file in case $DESTINATION changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we could, but the file is at the EXPORT level and we don't know if other installs put something else in there.

I'm not entirely sure what the completely correct solution is here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed a suggestion - If we require that the export name is unique, then we shouldn't have any problems with other corrosion_installs putting information into the same export.
What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that makes it good enough. The worst that happens is that people need to add another line to their config file.

Gtker and others added 3 commits September 3, 2024 16:01
It seems this was accidentally put on the check for a
`TARGET ${TARGET_NAME}-static` lib instead of the
`TARGET_TYPE STREQUAL *`
It seems something has been switched up and it's using CMAKE_BINARY_DIR
instead of CMAKE_CURRENT_BINARY_DIR.

Additionally, without a guard CMake will write the static/shared
definitions on every reconfigure, making the config file fail.
Switch back to CMAKE_BINARY_DIR as documented by the function signature.
If we anyway require a globally unique EXPORT_NAME,
then we don't need to use the current binary dir, making the file easier to find.
@jschwe jschwe changed the title corrosion_install: Move error checking into outer scope and add guards for configs corrosion_install: fix reconfiguring breaking EXPORTs Sep 3, 2024
@jschwe jschwe merged commit 97164ee into corrosion-rs:master Sep 3, 2024
36 checks passed
@gtker gtker deleted the wip-corrosion branch September 3, 2024 16:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants