From: "Jos I. Boumans" <[EMAIL PROTECTED]> > > Why the need for such an immensive framework? to be able to probe for > any type of file/function on any type of OS is not going to be trivial.
To look for every possibility yes that would be emmense. However, I wasn't expecting to go that far. There are a few cross-platform ways of looking for libraries and apps, as has been indicated by have_library() and the like. By refering to Module::Install, I meant the check module would be part of the distribution, and be called within Makefile.PL/Build.PL before calls to the appropriate build mechanism. The change to CPANPLUS would then be to detect any error within the buffer, that was from the check module, to indicate a 3rd party library or app was unavailable, or could not be determined. However, as there is currently no report to distiguish between this and other FAIL reports, no change to CPANPLUS would just create a FAIL report, as it does currently. The inclusion of any Alien module would then be at the request of author and the acceptance of the user, as currently happens with several Perl distributions (such as CPANPLUS itself when it determines which Perl modules need to be included in the prereqs). Always assuming that an Alien module exists for the required library/app. If it doesn't exist, it's simply a failing prerequisite, and thus requires the user to install it themselves. In many cases this may well be the prefered option for the user anyway. > But a relevent excerpt is this: > > So, what should an Alien module do? It should make sure that the > target is > installed and it should provide the caller with enough information to > use it. Another excerpt: "On installation, make sure the required package is there, otherwise install it." I read that to imply that the appropriate Alien module would know how to download and install the appropriate library/app. However, my mentioning the Alien module was aside, as I'm more interested in being able to use something like have_library(), etc to check whether a library or app is available with minimal hassle. From: "Rob Janes" <[EMAIL PROTECTED]> > > Jos, as an xs developer I am not likely to switch to Module::Build > anytime soon. I've got some more xs to build, with system > dependencies. How can my Makefile.PL throw a system dependency failure > to cpanplus? Is there any way for my Makefile.PL to throw an error and > diagnostic of any sort to CPANPLUS? For example, I'd like Makefile.PL > to bork a prereq if a system library is missing, or if there is no c > compiler. At the moment CPANPLUS would not know what to look for. However, with a standard string to indicate that a missing library/app cause the Makefile.PL/Build.PL to bork, CPANPLUS could be altered to check for it. However, this leads back to my other question as to what to call the report, as if the string is ignore, and CPANPLUS left as is, it would simply create a FAIL report, which some authors have taken issue with. From: "Rob Janes" <[EMAIL PROTECTED]> > my immediate problem is that Compress::Bzip2 build is failing, due to > missing compiler. the error is not being categorized imho properly. i > don't want to see every xs author having to write a check for the c > compiler, myself included Which is why I suggested something such as a Module::External that could simply check all the typical locations for a compiler. It won't be complete, but perhaps patches in the course of time will help. > i'd like to see the Makefile.PL throw a > distinguished error to cpan or cpanplus so that the error would not be > misclassified. You can, but currently there are only a few specific error strings that are picked up. And due to a change in the internals, which I'm looking at at the moment, the prepare stage doesn't create a report, so currently it won't get picked up straight away. Once I've sorted out the patch it will. > An NA error has been mentioned. I have no idea how to > throw an NA error. A simple die() with "No support for OS" or "OS unsupported" as the error string or the requirement of a Perl version higher than the current one are the current string captures for NA reports. It's this list I was thinking to extend, although the PERL_VERSION_TOO_LOW catch and any 3rd party app should really generate another type of report. Barbie. -- barbie (@missbarbell.co.uk) | Birmingham Perl Mongers user group | http://birmingham.pm.org
