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

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

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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]