http://www.perlmonks.org?node_id=458431


in reply to Re^2: Module::Build users -- please use the "traditional" create_makefile_pl option (no AIX?)
in thread Module::Build users -- please use the "traditional" create_makefile_pl option

Module::Build didn't work on AIX? I thought a major point of Module::Build's approach was to do things in Perl where stuff "just works" across many platforms.

Its not Perl its XS and C compiling. Everybody's compilers work differently and everybody's systems have things in different places and everybody has slightly different things broken. And once you've figured that all out you need to try it again for the next older version. And the next. And the next. Its a nightmare.

MakeMaker has figured this out over the years but the result is a tangled mess of code. Ken has written ExtUtils::CBuilder and ExtUtils::ParseXS which is a modularization of the XS and C voodoo from MakeMaker but its slow going. Don't think of it so much as mining MakeMaker for information as painfully extracting precious gems and oils from tar sand.

FWIW both ExtUtils::CBuilder and ExtUtils::ParseXS (and its improved xsubpp) have just gone into 5.9.x today.

Replies are listed 'Best First'.
Re: The world of pain that is XS compilation. (w/o XS?)
by tye (Sage) on May 19, 2005 at 03:24 UTC
    Its not Perl its XS and C compiling.

    But what I responded to said:

    Unfortunately at the time Module::Build wouldn't build/install on AIX 5.1 [...] Luckily the module I needed was pure perl so I could install it by hand

    Shrug.

    - tye        

      FWIW, it sounds like you're wondering why Module::Build didn't work for a pure perl module. If so, I misunderstood in my earlier post -- sorry, I'm kind of dense sometimes.

      Module::Build may well have worked fine for installing pure perl modules, I didn't bother to find out once its own 'make test' failed though. My policy with Module::Build, and any non-core CPAN module I want to install, is: If there is no "make test" provided, or I can't run "make test" to completion and can't easily figure out how to fix it or live with it, I don't use the module since there are probably other things lurking. Yeah, I'm paranoid, so YMMV.

Re: The world of pain that is XS compilation.
by ysth (Canon) on May 20, 2005 at 02:47 UTC
    In getting CBuilder to work in the perl source tree, I had to compare parts of CBuilder with their MM equivalent, and I have to say there were gems that got left behind (or were added after CBuilder was started?). One in particular that I remember was the limited support for cross-compiling that makemaker has.

    AIUI, the xsubpp isn't really improved: the code was just moved from a script to a module and the script now uses the module. From my perspective, the really significant impact of this is that xsubpp tests can now be written (but haven't yet been).

      That's correct, xsubpp wasn't improved at all. I did do some cleanup of code (adding "use strict" to some of it and lexicalizing variables) but that's about it. The main reason I wanted to stick it in a module was so that I could call its code - which after all, just reads in a file and writes another - without calling a subprocess.

      I also agree that there are certainly gems (or necessary kludges, in some cases) from MM's C-compilation code that aren't in CBuilder. I'm depending on people submitting bug reports (and patches for platforms I can't test on) so I can fix them.

      Since CBuilder and ParseXS went into the core, I've gotten lots of good patches and suggestions, which will make their way into the next version.

       -Ken