conda-build
conda-build copied to clipboard
Be robust against spaces in %SRC_DIR%.
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).
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.
Kindly bumping. The test failure seems spurious, and the CLA was signed on Jan. 31st.
@cla-bot check
The cla-bot has been summoned, and re-checked this pull request!
Kindly bumping again.
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.
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
?
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.
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.
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.
OK thanks!
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:
- Rebase and verify the changes still work
- Leave a comment with the current status
NOTE: If this pull request was closed prematurely, please leave a comment.
Thanks!
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:
- Rebase and verify the changes still work
- Leave a comment with the current status
NOTE: If this pull request was closed prematurely, please leave a comment.
Thanks!