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

Fix Integrator build script #139

Merged
merged 1 commit into from
Mar 27, 2022
Merged

Conversation

jschwe
Copy link
Collaborator

@jschwe jschwe commented Feb 6, 2022

We use COMMAND_EXPAND_LISTS, which also expands lists in generator
expressions. Therefore the values of the env variables will be space
seperated.

Closes #128

@ogoffart
Copy link
Collaborator

ogoffart commented Feb 6, 2022

Can there be a test?

Will there not be problems if the directories contains spaces? Or is that properly escaped. (Maybe that's another thing worth testing: spaces or special characters in the source and build paths)

@jschwe
Copy link
Collaborator Author

jschwe commented Feb 6, 2022

Will there not be problems if the directories contains spaces? Or is that properly escaped

I haven't tested, but I would imagine that to be problematic. I think there are probably also a couple of other places in our code that could be problematic for paths with spaces (but I'll look into that separately).
In this case, I guess that means we will have to add our own delimiter, because I don't think we can properly escape.

So that means I'll definitely also have to add a test.

@jschwe
Copy link
Collaborator Author

jschwe commented Mar 26, 2022

I finally got back to this. I chose : as a delimiter, since it can=t be part of a filename, and added a test with multiple librariers including a filepath with spaces.

@jschwe jschwe requested a review from ogoffart March 26, 2022 20:55
@@ -105,8 +105,13 @@ function(_add_cargo_build)
set (build_dir .)
endif()

set(link_libs "$<GENEX_EVAL:$<TARGET_PROPERTY:cargo-build_${target_name},CARGO_LINK_LIBRARIES>>")
set(search_dirs "$<GENEX_EVAL:$<TARGET_PROPERTY:cargo-build_${target_name},CARGO_LINK_DIRECTORIES>>")
# Join the list with `|` as a custom delimiter, since the `;` is expanded when passed
Copy link
Collaborator

Choose a reason for hiding this comment

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

Did you mean : here?
Path can contain : on Linux iirc.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, I changed to :, actually because PATH is : delimited. So using the same delimiter for our usecase seems reasonable. I adjusted the wording to make it clearer that file/directory paths cannot contain :.

cmake/Corrosion.cmake Outdated Show resolved Hide resolved
@@ -0,0 +1,10 @@
// Check that libraries located at a path containing a space can also be linked.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd go with a even more complex path for the test. Include a few symbol, some emoji, an such.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I added some chinese characters and emojis. I don't really want to add any of the ascii special characters, because then we would have to check what the common subset of supported special characters in filepath is across our supported operating systems and generators/compilers.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Looks like ninja 1.11 (which is not even out yet) would be required to support non-ansi filepaths on windows. See ninja-build/ninja#1915 for details.

Use a custom separator to prevent list expansion. Library paths
may contain spaces so we need to use a custom delimiter.
The `:` should work well as a custom delimiter, since it
can't be part of a valid filepath on any platform I know.

Closes corrosion-rs#128

Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
@jschwe jschwe merged commit 4d05458 into corrosion-rs:master Mar 27, 2022
@jschwe jschwe deleted the jschwe/fix-128 branch March 27, 2022 14:19
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.

corrosion_link_libraries doesn't seem to handle multiple libraries
2 participants