-
Notifications
You must be signed in to change notification settings - Fork 161
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
Make TmpNameAllArchs
obsolete by enhancing TmpName
#3702
Conversation
windows vs cygwin names is a pain. If you pass cygwin filenames to window executables, they will get confused, while cygwin executables will accept windows paths, so there is an argument windows paths are better. But we are inconsistent with what types of paths we give out all over the place. |
@ChrisJefferson I am of course happy to use a On the long run, we really need better Windows testing, too. If "somebody" could figure out how to setup package tests similar to https://travis-ci.org/gap-infra/gap-docker-pkg-tests-master but using Windows, that'd be awesome (regardless of whether it is based on AppVeyor (which we already use for Windows testing, but which I find otherwise rather clunky to use), Travis for Windows, Azure Pipelines, GitHub Actions, CircleCI, or whatever.... They all offer free Windows CI for open source projects in one way or another. |
I guess issue #2023 is related... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intention of ShortFileNameWindows
can be satisfied by TmpName
, thus not needed any longer.
On
I will continue with the rest of tests. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
And the last one.
|
|
Essentially, we move the added logic from TmpNameAllArchs to TmpName, but slightly tweaked, so that it matches the behavior of TmpDirectory. Also merge some Windows specific code in the GAP function `DirectoryTemporary` into the kernel function `FuncTmpDirectory`
Since parts of this PR were merged, I've now rebased it down to a single commit, which makes it much easier to see what is going on. I also changed it to not switch to using the controversial
So, I now went the opposite direction, and change |
I think before this merged I should test this under Windows properly, starting from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks fine, but then again I haven’t tested it with Windows. I look forward to the results of @alex-konovalov’s Windows testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested this on a Cygwin-free machine in Jenkins.
TmpNameAllArchs
obsolete by enhancing TmpName
Back in 2011, a new library function
TmpNameAllArchs
was added which wraps the kernel functionTmpName
and adds some Windows specific sauce to it. This PR enhancesTmpName
so thatTmpNameAllArchs
can be turned into a simple synonym forTmpName
. It does so by aligning the code ofFuncTmpName
andFuncTmpDirectory
more closely. (They still differ in that the latter honors the theTMPDIR
env var, the former does not; we might want to change that, but I didn't want to make too big a change in one go.There is another difference between the old and new code: the old used
C:/WINDOWS/Temp/
, the new uses/cygdrive/c/WINDOWS/Temp/
. I hope that doesn't matter or even is an improvement, but it would be really good if somebody with Windows access could verify that (beyond what little the tests in our test suite do).Resolves #3328
The other change in this PR is the removal of the library function
ShortFileNameWindows
which @hulpke added in 2009 but which hasn't ever been used by GAP or any package, as far as I can tell. It's also undocumented, and it seems not so useful to access 8.3 filenames these days. But perhaps I am mistaken, and there are usecases (in particular, I have no idea what the motivation for adding it back then was).