Re^4: Disappointed with latest Strawberry Perl (dmake ne nmake)

Please don't link/copy dmake to nmake. Just because I install Strawberry Perl doesn't mean I don't have other Perls or other things that use nmake. It seems a very bad idea to potentially break things that actually want/need nmake in a way that will likely be quite confusing to diagnose.

- tye

Comment on Re^4: Disappointed with latest Strawberry Perl (dmake ne nmake)

Replies are listed 'Best First'.
Re^5: Disappointed with latest Strawberry Perl (dmake ne nmake) by Tux (Canon) on Dec 31, 2007 at 09:43 UTC
Linking would be no trouble for you either, as for the other perl's, you'd have the path to make and nmake in a part of your $PATH that corresponds to the perl you are working with. As said, I now have 5 different perls happily living side by side in thre different environments. Enjoy, Have FUN! H.Merijn	[reply]
Re^6: Disappointed with latest Strawberry Perl (dmake ne nmake) by tye (Sage) on Dec 31, 2007 at 15:46 UTC
I don't understand your explanation. But it could certainly cause a problem for me. I currently have Strawberry Perl first in $PATH and when I want to build a module for non-strawberry Perl, I run "bperl Makefile.PL; nmake ...". That would fail if Strawberry Perl had installed a non-nmake program as "nmake". And the proposed solution sounds like the wrong way to go anyway. If Tk is using the wrong "make", then Tk should be patched to ask Perl which make to use. Making "nmake" mean "either nmake or some other make, depending on which order things are in $PATH" just makes things more confusing. - tye	[reply]