In which Adam rants about CPAN XS authors being stupid

Alias on 2008-01-07T07:53:14

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.


Exactly onto the point

janus on 2008-01-07T12:17:03

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.

Agreed.

LTjake on 2008-01-07T13:02:51

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] http://search.cpan.org/src/BRICAS/Linux-Input-Wiimote-0.04002/Makefile.PL

Amen

jdavidb on 2008-01-07T19:43:00

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 autodetect things in a way that trounces my attempt to communicate where those libraries are. And I emphatically do not want installation to pause and expect me to type an answer.

So it sounds like there's the makings of a solution there: have an external libraries registry available to CPAN.pm and allow Makefile.PL to query that registry. I'll tell /usr/local/perl/5.10.0 that I want to use the freeTDS located in /usr/local/perl/5.10.0/lib, I'll tell /home/me/perl/smoke/5.10.0 that I want to use the freeTDS located in /usr/lib, and I'll tell /app/weirddaemon/perl/5.6.1 that I want to use the freeTDS located in /var/extra/space/freeTDS.

Hooray

Ron Savage on 2008-01-08T04:06:05

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