From: Soren A <sor...@fa...> - 2002-11-25 22:27:11
|
"pascal barbedor" <pas...@fr...> wrote in news:001601c29392$30057ed0$bfb9933e@allalswqm99ewu: > recently i have compiled perl 58 with dmake etc.. but it is a dead end > because there is no further access to modules with dll built like > XML::LibXML, GD, or needing interfacing with apache (built only with > msvc) modperl. Yes, exactly. That is, there might be a work-around that I don't know about -- but even if there is I am just not much interested in having 'dmake' be my make tool. I spend enough time debugging the Makefile.PL's in Perl module packages, as it is; it makes it much worse when I don't care for or know the make tool that's going to be called upon to do the grunt work. > also if that build of perl with make on mingw is possible, will that > mean any module on CPAN no strictly system dependent will be usable > with that perl ? Hmm. I am not sure precisely what you mean, Pascal, so I will need to wander a bit and try to reconstruct the question from a basic perspective. Perl modules do come in two "flavors": those with a "C" (or less commonly, C++) back-end -- and then THOSE modules come in two "sub-flavors" of which the first is 'stand-alone' -- there's no special library dependency but all calls are to (presumably) standard system C-runtime lib functions; or the second type (subflavor) is those that have a dependency on some special library that might have its source included in the module package. An example of the latter would be "Compress::Zlib" which includes the Zlib source in its archive, so that if the user is on a system that doesn't have zlib ('-lz') available installed yet, s/he can make it at module build time. An example of the former would be "Cwd" which part of the Perl core and has C code but no dependency on some special external library which wouldn't otherwise be expected to be found on every system. An example of the "Compress::Zlib" type is GD, which you mentioned. And another (extreme) example of the second subflavor of the second flavor (modules with C code *and* external dependencies) would be "PerlMagick", a.k.a. Image::Magick, the Perl package for accessing the ImageMagick API in Perl. There are multiple layers of dependencies in that case, from the need to have a 'libMagick.[dll.]a' to that lib's dependencies on modules and graphics format libraries. TTBOMK nobody has yet figured out how to have Perl build all that automagically ;-) so there is a lot of manual preparatory work and head-scratching to be done before you are even ready to try building the Perl module. The first major 'flavor' is i.e. Archive::Tar (which, contrary to what people might think, has no C backend, IIRC). These are "pure Perl" modules in which all code is Perl and no C code needs compiling in order to install and use. Typically the most simple examples of such modules can be installed easily by anyone, even those without a C compiler (aghast!) or a 'make' utility, by simply figuring out based on a simple heuristic, where the module .pm file should placed in the perl tree, and cp ing it there. So, I have to guess (it's the only guess that makes sense) that you meant to wonder "will any basic *NIX-oriented module build on this (vapourware) perl we are discussing?" and I have to answer "I do not know". I think the results will be easy and good in many cases, but it is likely that in some (I think rare) specific cases there will C code that calls functions not available in MinGW (which means not available in the msvcrt.dll runtime, which is a very plain and not too-too standard ANSI-C-ish runtime). Only by trying will we know. It all mostly depends on how well we do with the basic port of core Perl to begin with. Config.pm (from config.sh) will contain the huge list of defined vs. undefined C functions that have been discovered on the system; our first task is to port Perl's 'Configure' (capital 'C') to MinGW/MSYS so that it runs properly to completion and causes a valid Config.pm to be generated. From there, I believe that the going will be slower as there may be a lot of MSVC++ - isms in the Perl src code that need to be fixed for MinGW. We need to get a "mingw/" subdir placed in the distro (with a "Makefile.SHs" in it), and a "hints/mingw" file as well. To do so will require someone to subscribe to p5p and get the attention of the Pumpking (I *think* that's still Jarkko (sp?) at this point but I am not sure). What we *will* definitely get by building this dreamPerl is all the Win32:: stuff or a good part thereof. The special namespace Win32:: basically denotes special facilities and porting for Win32 Perl and mainly, access to the Win32 API. There are many modules in that namespace and some of them are very desirable. And Cygwin Perl doesn't have them. > anyway I am very interested in this build possible, if that gives > full access to other modules afterwards. Yep, that's exactly the reason why it's desirable. Otherwise, msysperl (or cygwinperl) would be sufficient and there'd be little need to go looking for so much discomfort. CPAN.pm depends for its proper functioning on a Perl that's been built and installed in-place (or with GREAT care taken in preparing it for relocation / propagation to a number of very similar workstations) and this dreamPerl will be ready to download, build and install modules using CPAN (or CPAN2) which is a convenience that Win32-Perl users have long only looked at from afar in envy and frustration. I also want dreamPerl to be fully able to to satisfy the requirements of the Inline:: system (which allows the use of C or other languages "inline" in Perl code). Best, Soren A |