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


in reply to Re: Module::Build users -- please use the "traditional" create_makefile_pl option
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. I'm curious what they got wrong, as this seems to belie that justification.

Note that I've worked on AIX and realize that it is "strange" in ways that most other Unixes are not (well HP/UX can be very strange as well). I'm not jumping to the conclusion that this failure really does reflect badly on Module::Build, I'm just curious for more details (at which point I might jump to that conclusions or not).

- tye        

  • Comment on Re^2: Module::Build users -- please use the "traditional" create_makefile_pl option (no AIX?)

Replies are listed 'Best First'.
Re^3: Module::Build users -- please use the "traditional" create_makefile_pl option (no AIX?)
by bluto (Curate) on May 18, 2005 at 19:22 UTC
    It didn't at the time (10/2003). The changes file says this was fixed in 0.22 (01/2004), which I think I noticed a month or two after that. It has this interesting comment... 

    AIX also massages some very naughty bits (MakeMaker macro variables) 
in $Config{lddlflags} that should never have been put there, but 
alas, they're there, so we find & resolve them.

    [download]

    My email at the time says these were getting passed to the linker without being interpolated (during a 'make test' of Module::Build). So either it's an AIX/perl issue or Module::Build was making assumptions it shouldn't have.

[reply]
[d/l]
The world of pain that is XS compilation.
by Anonymous Monk on May 18, 2005 at 20:41 UTC
    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.

[reply]
      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        

[reply]
        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.

[reply]
      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).

[reply]

        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

[reply]

In Section Meditations