use Perl

• The "Windows == n/dmake" assumption. (Score:2)

  by schwern (1528)

  > Are there any Win32-specific issues that would mean EU:MM generates nmake-style make content?
  
  Yes. The issue is MakeMaker generates n/dmake-style make content. It will not work with GNU make... though you might want to test that. I'm not adverse to someone trying to change that but "Windows == n/dmake" is pretty deeply embedded in MakeMaker. MakeMaker is broken down by operating system, not make version.
  
  Worse, its difficult for MakeMaker to know what make is going to be used to build the module at t
  • Re:The "Windows == n/dmake" assumption. (Score:1)

    by dagolden (6584)

    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. (Score:2)

      by schwern (1528)

      > 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 buil
      • Re:The "Windows == n/dmake" assumption. (Score:1)

        by dagolden (6584)

        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. (Score:1)

          by Alias (5735)

          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.