All the Perl that's Practical to Extract and Report
use Perl Log In
Alias (5735)
Building C modules hurts
Slowly working through the various C elements people have requested.
Compress::Zlib, Compress::Bzip2, XML::LibXML(libxml2+zlib+iconv) are all green. Text::Iconv doesn't build properly, but I'm happy to ignore that for now as I don't think anyone actually needs it specifically, they mostly use iconv via XML::LibXML.
SQLite works, except for the previously mentioned spurious failing test (I need to force the install for it).
Expat is building but doesn't link right at run-time, but I have some other strategies to try still.
LibXSLT is a bust, because pexports crashes trying to extract the
One of the more annoying and depressing things I've noticed is how sad the state of build C libraries is, particularly with regards to having the compiler find header files.
Because I'm in a slightly unusual situation (using one Perl install to build another Perl install) I'm seeing all sorts of hideous behaviours.
For example, Compress::Bzip2 uses ExtUtils::Liblist to search for bzlib2 during Makefile.PL, which pulls the include path from $Config{libpath} and ignores the environment or any Makefile.PL INC param, but then at build time, MakeMaker overwrites the resulting INC provided to WriteMakeFile with the command line Makefile.PL INC param, resulting in the library being unfindable at compile time.
Other modules use the command line INC but ignore the environment, or ignore the command line but use the environment, or overwrite one with the other and so on and so forth.
Not to mention the entire concept of passing important params to Makefile.PL is utterly rediculous, because it effectively prohibits the installation via the CPAN client, because you can only configure the CPAN client to use ONE set of Makefile.PL params for ALL modules.
Which doesn't work either, because some modules ignore command line params.
Worse, I don't know what SHOULD be the correct approach out of %Config + command line + environment, so I can't even be sure who is at fault.
And the whole time I'm thinking, "If only C had a CCAN"...
sigh
because that's exactly how much difference there is. :-)
--Larry Wall in <10209@jpl-devvax.JPL.NASA.GOV>
Re: Building C modules hurts (Score:1)
I feel your pain!
What I found the best approach to automation was to patch the Makefile.PL respectively to ask the module authors to accept the changes. Imager [cpan.org] reads some environment variables in addition to command line switches to the Makefile.PL for example, which makes configuration/installation from the outside far easier, as there is no need to download and patch the files.
A second approach might be to use the distroprefs feature of CPAN [cpan.org], where you can apply your own patches to distributions every
Re: (Score:1)
What annoys me is I don't know what the "right" solution to this stuff is!
Re: (Score:1)