conda-build icon indicating copy to clipboard operation
conda-build copied to clipboard

Be robust against spaces in %SRC_DIR%.

Open anntzer opened this issue 5 years ago • 11 comments

The build directory simply needs to be quoted. This can be tested by trying to build any recipe after installing conda in a path that contains spaces (e.g., if your username contains spaces).

anntzer avatar Jan 31 '20 11:01 anntzer

We require contributors to sign our Contributor License Agreement, and we don't have one on file for @anntzer. In order for us to review and merge your code, please e-sign the PDF at https://conda.io/en/latest/contributing.html#conda-contributor-license-agreement. We then need to manually verify your signature. We will ping the bot to refresh the PR status when we have confirmed your signature.

cla-bot[bot] avatar Jan 31 '20 11:01 cla-bot[bot]

Kindly bumping. The test failure seems spurious, and the CLA was signed on Jan. 31st.

anntzer avatar May 08 '20 19:05 anntzer

@cla-bot check

jjhelmus avatar May 13 '20 15:05 jjhelmus

The cla-bot has been summoned, and re-checked this pull request!

cla-bot[bot] avatar May 13 '20 15:05 cla-bot[bot]

Kindly bumping again.

anntzer avatar Dec 16 '20 13:12 anntzer

Thanks for the PR and the ping, sorry it took so long to get back to you!

My stance is that many build tools (e.g. GNU make) do not handle paths in spaces and therefore conda-build should never be performed in such a compilation root. You should use the --croot option to specify a build directory that does not have this issue.

If you want to update this PR so that it also warns strongly when a space is detected then I am "OK" with this, even if it sends out a signal that we think it is valid to try to attempt to compile any significant percentage of software (on any OS) in a path containing spaces.

mingwandroid avatar Dec 16 '20 16:12 mingwandroid

Thanks for the PR and the ping, sorry it took so long to get back to you!

No worries, thanks for the review.

My stance is that many build tools (e.g. GNU make) do not handle paths in spaces

My understanding is that this just depends on whether the makefile handles quotation carefully, although I may be wrong.

and therefore conda-build should never be performed in such a compilation root. You should use the --croot option to specify a build directory that does not have this issue. If you want to update this PR so that it also warns strongly when a space is detected then I am "OK" with this, even if it sends out a signal that we think it is valid to try to attempt to compile any significant percentage of software (on any OS) in a path containing spaces.

Thanks for pointing out the existence of --croot. It may be cleaner to just detect at the very beginning if there's spaces in the workdir, and if so, immediately error out cleanly with a suggestion to use --croot?

anntzer avatar Dec 16 '20 17:12 anntzer

My understanding is that this just depends on whether the makefile handles quotation carefully, although I may be wrong

I am afraid in general this is untrue. In general mo one takes care (either humans or tools like autotools ad cmake) over this when generating Makefiles. The same is likely true of ninja, meson and the other Makefile generators too but I'm not sure. Either way, autotools is incapable of supporting this use-case.

mingwandroid avatar Dec 16 '20 17:12 mingwandroid

Thanks for pointing out the existence of --croot. It may be cleaner to just detect at the very beginning if there's spaces in the workdir, and if so, immediately error out cleanly with a suggestion to use --croot?

For me, maybe an error (configurable but defaulting to true, override-able from both cmdline and from within meta.yaml (e.g. build/can_handle_spaces), or this PR plus a strong warning would be great.

mingwandroid avatar Dec 16 '20 17:12 mingwandroid

Given that I now know the workaround (thanks for pointing it out :)) I'll leave the new tasks to someone else for now if anyone wants to pick them up, but may revisit this in the future if no one does. Feel free to take over the PR, or to close it for now.

anntzer avatar Dec 16 '20 17:12 anntzer

OK thanks!

mingwandroid avatar Dec 16 '20 17:12 mingwandroid

Hi there, thank you for your contribution!

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this pull request to remain open please:

  1. Rebase and verify the changes still work
  2. Leave a comment with the current status

NOTE: If this pull request was closed prematurely, please leave a comment.

Thanks!

github-actions[bot] avatar Jul 28 '23 04:07 github-actions[bot]

Hi there, thank you for your contribution!

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this pull request to remain open please:

  1. Rebase and verify the changes still work
  2. Leave a comment with the current status

NOTE: If this pull request was closed prematurely, please leave a comment.

Thanks!

github-actions[bot] avatar Jul 28 '23 04:07 github-actions[bot]