Fix cmake handling of paths with spaces (RP2040)

[TankedThomas]

Fix cmake handling of paths with spaces

Description

Double quotes are added to cmake variables in order to handle pathname spaces (or other special characters).

Test Steps

When building with the related cmake files over on the raspberrypi/debugprobe repo, I ran into issues with my pathnames having spaces in them.
The same thing might happen here, so the maintainers of debugprobe suggested pushing this fix upstream.

Checklist:

• I have tested my changes. No regression in existing tests.
  I'm not sure how to build FreeRTOS to test, but this should work fine according to my tests with raspberrypi/debugprobe
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.
  I don't believe unit test changes should be necessary here.

Related Issue

Related raspberrypi/debugprobe pull request

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[AniruddhaKanhere]

Thank you @TankedThomas for your contribution. The changes look correct to me. I have approved the CI check run - let us see if that passes successfully.

[AhmedIsmail02]

@TankedThomas Thank you for your contribution, I've checked the RP2040 port part in portable/CMakeLists.txt file where I can see ${CMAKE_CURRENT_LIST_DIR} which produces an absolute path doesn't have the double quotes, how is it working without your changes?

[kar-rahul-aws]

@AhmedIsmail02 I think this is because CMake looks for whitespace to separate arguments before it evaluates any variables.
For example:-

add_custom_target(PrintMessage
    COMMAND ${CMAKE_COMMAND} -E echo
                "$<IF:$<CONFIG:Debug>,This is debug,Must be something else>"
)

Here double quotes are needed , To prevent CMake from treating the spaces in the expression as argument separators.

add_custom_target(PrintMessage
    COMMAND ${CMAKE_COMMAND} -E echo
                $<IF:${is_debug},${msg_debug},${msg_other}>
)

No quotes are needed around the final $IF:... generator expression in the above, due to lack of white spaces.

In the similar way, in RP2040 port part in portable/CMakeLists.txt
there are no white spaces, so when ${CMAKE_CURRENT_LIST_DIR} or ${FREERTS_PORT} is substituted, it retains spaces but does not get split further.

[AhmedIsmail02]

@kar-rahul-aws Thanks for your reply, As far as I understand and according to your reply I think some of the changes are not needed since CMake looks for white spaces separator before evaluating variables. Hence, paths containing white spaces shouldn't be an issue in that case. I believe that wrapping strings between double quotes is generally the safer option, but it might be a bit confusing for users/developers if it's not consistent.

[kilograham]

@kar-rahul-aws Thanks for your reply, As far as I understand and according to your reply I think some of the changes are not needed since CMake looks for white spaces separator before evaluating variables. Hence, paths containing white spaces shouldn't be an issue in that case. I believe that wrapping strings between double quotes is generally the safer option, but it might be a bit confusing for users/developers if it's not consistent.

I agree; the issue doesn't identify which unquoted paths are a problem; i think it would be much preferable to only modify those if the number is limited

[kilograham]

I assume it is just the get_filename_component calls

[aggarg]

@TankedThomas Can you please check @kilograham's suggestion and limit the changes to only the required ones?

[TankedThomas]

Sorry everyone, really busy this week. I'll get back to you ASAP but it probably won't be until the end of next week.

[rohitmadan07]

Hi @TankedThomas did you get some time to look into this ?

[kar-rahul-aws]

Hi @TankedThomas are you able to look into the code changes suggested above or you want us to make the changes ?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[TankedThomas]

Apologies, I got my work done (later than I expected) then had computer issues! Terrible timing...
Now that I finally have some time, I've gone back to have a look at this.

To be frank, I don't remember exactly where the problem was occurring but after reviewing all the related pull requests and issues, I know what I should be looking at: it should have been happening when running cmake for building debugprobe. The spacing issue was because I have a directory called Raspberry Pi.

However, I can no longer produce the error with the unmodified code.
I'm using Debian 12 on WSL, so maybe that was causing a problem with path traversal (especially given how broken my Windows installation has become recently), but how it would have fixed itself, I'm not sure.

So I haven't made any more changes at this stage. I see my pull request for debugprobe was reversed anyway (to be fair, I agree the changes were probably too heavy-handed) (never mind, it hasn't been committed yet, but the reversal doesn't change the rest of this comment - I tested it), and again, that doesn't seem to have caused an issue after freshly cloning that repo. I even tried building against the commit before mine on debugprobe but the issue is gone... somehow.

At the risk of sounding incompetent, I have no explanation for why I no longer have an issue, but unless someone else can reproduce the issue, it's probably better to leave the code unmodified. If everyone agrees, I can just close this pull request.

[kar-rahul-aws]

Hi @TankedThomas
Thanks for taking the time to verify that the issue is not being reproduced now. Since we are not able to reproduce the issue on our end, let's close this issue. If you encounter this issue in the future, please feel free to open a new issue.