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 .def file. So I'm skipping it for this release. Anyone that wants to look at pexports is welcome to try to get it working for me.
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
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 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, where you can apply your own patches to distributions every time CPAN installs them. That still means the manual labor of patching a distribution into submission, but after you've created your patch, CPAN can apply it for you and you can release that patch onto CPAN for others to use as well.
Re: Building C modules hurts
Alias on 2007-11-14T08:13:20
I can deal with talking to authors (or taking stuff over).
What annoys me is I don't know what the "right" solution to this stuff is!Re: Building C modules hurts
fbcit on 2008-01-24T00:49:45
Hi, I've been working on getting libxslt compiled for use under Strawberry Perl. I'm stuck right now, but did get beyond pexport by using Dependency Walker. You can read my notes in general here:
http://wiki.koha.org/doku.php?id=en:installation:win32:koha_3_win32_installer_pr oject
and specifically to XML::LibXSLT here:
http://wiki.koha.org/doku.php?id=en:installation:win32:koha_3_win32_installer_pr oject#xmllibxslt
Any thoughts and/or suggestions would be greatly appriciated!
Regards, Chris
