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, ExtUtils::MakeMaker::Unix::test was “fixing” the specification for test files only if the nmake is being used.
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 say 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 repo. 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.