Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BLD: Use cygpath utility for path conversion in cyg2win32 #19547

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

Merged
merged 3 commits into from
Jul 23, 2021

Conversation

DWesl
Copy link
Contributor

@DWesl DWesl commented Jul 22, 2021

The old function only handled the default /cygdrive prefix. This
can be customized to different values: / and /mnt are both common.
/proc/cygdrive does the same thing, regardless of user customization.

The old function would also not convert absolute paths unless they were under /cygdrive,
which wouldn't work unless Cygwin was installed in the root of its drive.
Installing Cygwin in the root of a drive is not recommended.

cygpath handles all of these. There's also a C function if you'd prefer to avoid the fork() call, which tends to be slow on Cygwin.

I should note that this function seems to be called only when using the Absoft compilers, and only changes the path on Cygwin.
Path conversion like this is only useful when calling a Windows program from Cygwin. 64-bit Windows long int is 32 bits, 64-bit Cygwin long int is 64 bits, and I'm pretty sure Windows compilers expect to use the Windows C runtime library, while Cygwin native compilers expect to use Newlib with a few extra features. I remember CPython having warnings about using the wrong version of Visual Studio to compile extension modules on Windows, so I don't know that this would work even if everything's 32 bit.

This function seems to have been added in 575d373 and not touched since.

Extracted from #18308.

The old function only handled the default `/cygdrive` prefix.  This
can be customized to different values: `/` and `/mnt` are both common.
`/proc/cygdrive` does the same thing, regardless of user customization.

`cygpath` handles all of these.  There's also a C function if you'd
prefer to avoid the `fork()` call, which tends to be slow on Cygwin.

Edit: Fix the cyg2win32 function to have correct types.

It returned bytes earlier; this should return a string.

Edit: Fix docsrting to follow numpydoc.

BLD,DOC: Expand documentation for cyg2win32

Fix a misleading statement, and expand on the things `cygpath`
handles that can otherwise be tricky to get right.
@github-actions github-actions bot added the 36 - Build Build related PR label Jul 22, 2021
@charris
Copy link
Member

charris commented Jul 23, 2021

Is falling back to the original path the best response to a failure?

@DWesl
Copy link
Contributor Author

DWesl commented Jul 23, 2021

It's not worse than what's currently done. It will work for relative paths. I don't remember how much of what gets passed to the compilers is relative vs. absolute paths.

The cygpath call would only fail if somehow the install missed the cygpath utility, or if the environment is hostile to fork(). These are both less of a concern with a Windows compiler than a Cygwin compiler, but still not a great sign.

So, the options I can think of:

  • Fall back to the original path, maybe warning if that path is absolute
  • Let the CalledProcessError propagate
  • Substitute a different error and try to produce a better error message

I suspect anyone who knows enough to be able to convince a Cygwin python to use Absoft compilers for NumPy will understand the cygpath error message, so I'll implement the second option.

The only reasons I can think for this to fail are an incomplete
installation or an environment hostile to fork(), both of which should
probably be fixed before trying to compile NumPy.
@charris charris merged commit c3d1107 into numpy:main Jul 23, 2021
@charris
Copy link
Member

charris commented Jul 23, 2021

Lets give it a shot. Thanks @DWesl .

@DWesl DWesl deleted the cyg2win32-use-cygpath branch December 24, 2021 00:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
36 - Build Build related PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants