Re: Module::Build users -- please use the "traditional" create_makefile_pl option

[bluto]

in reply to Module::Build users -- please use the "traditional" create_makefile_pl option

If you someday start using actual features of Module::Build that are not supported by MakeMaker, you can change it then.

I'd also suggest that until Module::Build is known to work on a lot of platforms (i.e. close to what the baseline perl supports) that authors supply an oldstyle Makefile.PL.

One module that I had been using for a long time, and wanted to upgrade for additional features/fixes, started requiring Module::Build in order to install it. Unfortunately at the time Module::Build wouldn't build/install on AIX 5.1 and its author was unfamiliar with AIX. Since AIX isn't well known this understandably took a while for him to debug/fix (of which I'm very greatful). Luckily the module I needed was pure perl so I could install it by hand in the meantime. If it wasn't I'd have to support an older version of the module indefinitely and eventually consider rewriting a fair amount of code to avoid using it down the road.

[tye]

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).

[bluto]

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.

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.

[Anonymous Monk]

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.

[tye]

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.

[ysth]

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).

[adrianh]

I'd also suggest that until Module::Build is known to work on a lot of platforms (i.e. close to what the baseline perl supports) that authors supply an oldstyle Makefile.PL.

Which was exactly what perrin is suggesting. If you use the "traditional" create_makefile_pl option in M::B you'll get a normal Makefile.PL generated that doesn't depend on M::B.

[bluto]

No, I'm probably not being clear enough. What I'm suggesting they do is supply a legacy Makefile.PL that works totally independant of having M::B installed at all. Even if it's named something else (e.g. Makefile.Legacy.PL) to keep it out of the way, that would be fine. In my case perhaps M::B would have worked to generate one with the "traditional" option -- I don't know. I didn't want to find out because it failed 'make test', I couldn't fix it, so I didn't trust it. In my current work environment I've found I need to be very conservative, so YMMV.

[adrianh]

No, I'm probably not being clear enough. What I'm suggesting they do is supply a legacy Makefile.PL that works totally independant of having M::B installed at all.

No, I'm probably not being clear enough :-)

The the "traditional" create_makefile_pl option in M::B produces a normal Makefile.PL file at distribution time that uses EU::MM. So the package you download from CPAN has a Makefile.PL that you can use without having M::B installed - and a Build.PL if you do have M::B installed.

Hopefully this makes some vague sort of sense :-)