Re^4: Avoid headaches from Strawberry Perl 5.10.0 and binary SVK

[xdg]

No idea. I didn't write it. Maybe someone thought it would help in finding the DLL? (Superstition, I think.) Certainly, my hack of renaming and stripping all the PATH munging out seems to be working just fine.

[BrowserUk]

Maybe someone thought it would help in finding the DLL? (Superstition, I think.)

You're probably right. Unfortunately there are lots of these "belt and braces" superstitions floating around in the Win32 Perl distributions, makefiles etc.

There have been several variations in the DLL search path ordering over the years, and they recently added a new one, but in all cases, the first place looked at is the directory from which the executable requiring the DLL, was loaded. That has remained constant. That's another reason it would make sense to place the dlls created by compiled XS packages into the <perl>/bin directory.

And these bat file wrappers create far more problems than they solve. I never use them personally. I just do not consider the single advantage they have to be worth all the other problems they create.

I've had a couple of attempts over the years to see what if any of this cruft could be eliminated. But the reasons why things were done these ways is lost in the annals of history and so you can never be sure that if you remove/change something that you won't be breaking some obscure dependancy for someone, somewhere. And with backward compatibility given such a high priority...