Yesterday, I outlined why and how buggy tests involving hard-coded and/or interpolated paths can remain undetected for so long.
It turns out, in some cases,
"fixing" the specification for test files only if the
nmake is being
At first, I thought, EUMM had been doing this for a long time. I also had work to do, so I did not look carefully. Now, waiting for a another SAS job to finish, I see that the "fixing" of paths was introduced recently, in commit 006d5525 on November 3rd:
There is a bug in nmake that appears if these conditions are met:
- A command is enclosed in quotes
- The first parameter to that command contains a /
nmake adds a space prior to the first / in the first parameter, if the command is in quotes.
't/*.t' was being passed as 't /*.t'
The solution is to translate '/' to '\' only when the make utility is nmake.
On the one hand, I understand the desire to try to limit potential damage when changing something that appears to work fine.
On the other hand, I do not understand the resistance to using platfom-specific paths.
The fact is, on Windows, the platform specific directory separator in paths is '\'. Sure, internally a lot of functions understand paths with containing '/' as well, but that is hardly a valid reason to assume every program to which you are passing arguments via the shell is going to be fine with using '/'.
In fact, I would submit to you that if
dmake has problems with Windows
style directory separators on Windows in the cmd.exe shell, then I would
dmake is broken, not
nmake for failing to deal perfectly with
Unix style directory separators on Windows.
I personally would not recommend taking the risk of making a wholesale change to EUMM at this point.
After all, the only trouble it has caused so far is to expose unwarranted assumptions in some tests about hard coding paths, and interpolating variables containing paths in to regular expression patterns.
I am just happy to figure out why I had not run into this problem before even though I always built perls with the VS Express tools, and Windows SDKs before Visual Studio 2013 Community Edition became available.
Gabor keeps asking whether I have set up a smoker or submitted pull requests: The answer is: Sorta kinda. I decided to sign up for a Microsoft Azure Trial, and I am in the process of setting up a VM with a recent version of Perl, and the Microsoft toolchain. It should be up and working by the end of this week.
As for pull requests, it takes time to put those together. I first
needed to go through hours of
fun just to get to
the point I could type
dzil test in my GitHub clone of App::Cmd
dzil fans might think I am
stupid, but, still …
At the end of that process, my proposed fix ended up breaking the module on non-Microsoft toolchains because of this recently introduced gem in EUMM.
In the mean time, I put the modules whose tests are broken because of assumptions about paths on my blog, so, once again, when I am waiting for things to run on remote systems, I can come back to them, and compose pull requests.
I would love to be able to get to a point where GD builds without problems, but, that's a whole other story.