Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

  (email not shown publicly)

Journal of Alias (5735)

Monday January 07, 2008
02:53 AM

In which Adam rants about CPAN XS authors being stupid

[ #35315 ]

One of the bigger remaining problems the CPAN has yet to meet is the problem of cleanly installing C libraries, and the modules related to them.

Well no freaking wonder!

Having read through a number of Makefile.PLs, many by experienced CPAN authors who understand consensus building, I'm amazed this crap works at all.

You'd think by now we'd have reached some level of understanding that the CPAN clients need to communicate to the module configure script (Makefile.PL|Build.PL) where to find standard collections of libraries.

But no! Instead just about EVERY SINGLE MODULE just HAS to do it in a completely separate way.

The vaguely "standard" way is to take LIBS and INC params to Makefile.PL, which EU:MM will use to build the compiler command lines.

Of course, some modules will ignore this.

Some will try to incorrectly autodetect installations and OVERWRITE the LIBS values.

Or to make matters worse, some will INSIST on special Makefile.PL params all of their own.

Are you people nuts? The CPAN -> Makefile.PL interface doesn't support you randomly inventing new params and expecting people to fill them in. The user has NO idea what the hell you are talking about, because he only wanted some end-us module, he's in no position to start filling in values 7 layers of dependency recursion up the chain.

Even worse, when I asked if there was a "proper" way to do this, someone actually suggested the "right" way to install all modules was for the user to THEMSELVES read every single README, and follow the instructions.

People, the entire freaking point here is that NO user will or should ever have to read or learn ANYTHING in order to install modules.

So in actual install scenarios, THERE IS NO USER!

People trying to play games with their Makefile.PLs need to start getting it into their head that the ONLY way their module is going to be installed is by machine.

You don't have the freedom to demand additional configuration information, you don't have the freedom to ask questions in configure scripts, and you sure as hell don't have the freedom to just randomly invent new ways of doing things, and completely ignore the standard ways.

And if there isn't a standard way, well dammit put together a posse of like-minded people and CREATE one.

And now I'm off to see if I can't just start dictating a "standard" way to describe where libraries are, cause I'm sick of playing with XML::Parser and OpenSSH and LibXML and Zlib and a dozen other modules that all want to do library discover in different and incompatible ways.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Having ported more than a few CPAN modules i can only confirm this mess.
    I'd welcome every step towards unified configuration handling of XS modules.
  • I had the same issue working on Linux-Input-Wiimote [1]. I canvased several other XS modules and couldn't really see any similarities between any of the approaches.

    Using Devel::Checklib seems to work pretty well, though.

    [1] []
  • I've been saying that Makefile.PL shouldn't take user input forever, but very intelligent and experienced module authors have been telling me I am wrong, or that they like the freedom.

    I do want to be able to have multiple independent installations of both Perl and external libraries. I do want some way to tell my CPAN shell where those external libraries, so that the CPAN shell can tell Makefile.PL (or whatever). I do not want to have to pass parameters to Makefile.PL. I do not want Makefile.PL to auto

    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • And one day I'll be able to install modules via a CGI script without keeping my fingers crossed.

    Perhaps there are 2 aspects to this:
    o A standard (he, he) i.e. default install, which does not require/accept user input
    o A standard way of overriding the default install