With Strawberry alpha 1 out, and with a positive response, it's time for Vanilla to start looks for ways to break itself again. There's not much use being "experimental" if you don't go looking for trouble.
After some issues installing Wx.pm (which strictly requires GNU make) Mattias expressed surprise that we had a MinGW setup that _didn't_ have GNU make available.
After a quick bit of research, it would seem that indeed there is what seems to be a perfectly workable native GNU make.exe now (in fact, a couple of them).
So before we make the switch in Vanilla to see what happens, my question to the learned readers of use.perl.org is...
Will this work? Are there any Win32-specific issues that would mean EU:MM generates nmake-style make content? Can you see any other problems we might have moving from dmake to GNU make?
Re:The "Windows == n/dmake" assumption.
dagolden on 2006-07-13T12:27:42
Michael -- thanks for the response. Always helpful to get it straight from the source. However, about this:
Worse, its difficult for MakeMaker to know what make is going to be used to build the module at the time it writes the Makefile. It can only guess from whatever was used to build perl.What's wrong with using that assumption, supplemented with an environment variable to change that default, e.g.
PERL_MM_MAKE?Re:The "Windows == n/dmake" assumption.
schwern on 2006-07-14T00:15:03
> What's wrong with using that assumption
There's a universal problem with trying to divine the current state of the system from what the state was when Perl was built (ie. using Config.pm). Binary distribution of Perl, particularly on Operating Systems lacking a strong packaging system, are particularly bitten by this problem since the individual binary distributions you install are not coordinated. Windows is one such OS. The two most common problems are the C compiler and make.
Let's say Perl is built using nmake. User downloads that Perl. They have no make, so they grab nmake. MakeMaker generates dmake-style Makefiles. Crap doesn't work. The user, getting weird syntax errors from the Makefile, doesn't know what to do next.
Its also annoying that they'd have to remember to type "MAKE=nmake" all the time. You can edit Config.pm, but that's not the sort of thing I want to encourage.
In short, most people won't be able to figure out the work around. And the work arounds suck.
MakeMaker could try to be clever, sniff around in the PATH and look for a make to use. Except Unix users often have more than one make. And Windows users often fail to have make in their path.
What's really needed, and this potentially solves a huge pile of MakeMaker issues, is ~/.makemakerrc.
Makefile.PL:
MAKE=nmake
PREFIX=~
LIB=~/lib/perl5
install:
UNINST=1
Or something like that.
> supplemented with an environment variable to change that default, e.g. PERL_MM_MAKE?
You can currently override with MAKE either as an environment variable or a Makefile.PL argument.Re:The "Windows == n/dmake" assumption.
dagolden on 2006-07-14T14:43:02
I hadn't realized how extensive the current attempt to divine the current state already is.
But yhere's already an nmake/dmake assumption based on Config.pm, so it sounds like adding "make" to that list is a matter of work rather than a matter of philosophy. (That's still a barrier, of course.)
As for
.makemakerrc, the great work on File::HomeDir means that even CPAN.pm is now relying upon it, so its going core, so cross platform support for a .makemakerrc becomes quite a bit easier. Re:The "Windows == n/dmake" assumption.
Alias on 2006-07-15T01:34:25
It doesn't rely on it (yet), it merely uses it opportunistically, like a number of other modules. CPAN.pm is an extremely pragmatic beast.
That said, I fully expect File::HomeDir to go core _eventually_ just because it should theoretically be able to eventually get good enough platform coverage, I just don't see it in the near future.
