On Jun 17, 2005, at 7:49 PM, Rob Janes wrote:
so basically the executive summary is that cpanplus does not report
adequately system dependency failures, like a missing c compiler or a
missing library.
As outlined in my other email, that is because it can not (it has no
way of knowing that a missing system dependency
was the reason for a failure), nor should it (as an installer should be
able to interpret installation errors)
The idea is that perl xs modules have prereqs that are external to
perl, be they compilers, utilities, file naming conventions (to
backslash or not to backslash), libraries, etc. Failure in this
regard is essentially a prereq failure. ExtUtils::MakeMaker and M::B
would be changed to understand the concept of an external prereq.
This external prereq would be tested by a piece of custom code which
the module author would have to write, as I did with Compress::Bzip2
to test for the bzlib library. Likely E::M and M::B would have a list
of "names" of external prereqs that would be understood, and reported
on by the custom piece of code. The yaml file generated by E::M and
M::B would list these external prereqs, by name and description.
CPANPLUS understands perl prereqs. external prereqs would be more
difficult, but if we had a naming convention some basic external
prereqs could be preprepared since they are everywhere, like for
example system_cc=>"a c compiler", system_libbz2=>"bzlib devel
library". maybe something user_xxx=>"my custom ext. prereq" for
external prereqs requiring helper subroutines.
What you're describing here is what's covered by the 'Alien' idea; to
have a perl module specifically responsible for
satisfying a non-perl prereq (and trust me, a lot of thought has gone
into this). The hard part is that this would
require a package manager as rigid and advanced as dpkg to pull off,
and perl has none. And that leaves aside the
desirability of wanting to enthrust a package manager on users, rather
than interacting with their package manager
of choice for the OS they run... but i digress.
The Alien manifesto:
http://search.cpan.org/~abergman/Alien-0.91/lib/Alien.pm
An implementation for Alien for compress::zlib:
http://search.cpan.org/~kane/Alien-Zlib-0.00_01/lib/Alien/Zlib.pm
with perl xs, i just made CPANPLUS's check for prereqs more
complicated. E::M and M::B would have to assist in this. i think
currently cpanplus uses the yaml to check the prereqs and bails before
it even runs the .PL file, correct me if i'm wrong.
You're wrong :)
CPANPLUS runs 'perl Makefille.PL' and parses the makefile for
dependencies. In case of Buid.PL it asks the Module::Build
API what the dependencies are.
ok then, both scenarios. cpanplus runs .PL file and picks up prereq
failures from the logfile. this one is easy, the .PL file just has to
report on the external prereq failures.
For Makefile.PL this is correct. For Module::Build, again, we ask the
API.
cpanplus reads the yaml and checks for prereqs, and schedules perl
prereqs for loading.
CPANPLUS never reads the yaml file
for cpanplus to check for external prereqs, with a naming convention
there would be some prereqs it could check for itself, but more
generally it will have to call the .PL file with some special options
to make the .PL check the prereqs.
We'd need a standard for these options, along with support from EU::MM,
and M::B, as well as a way of unambiguously
probing the result, as well as interpreting the result.
when invoked with those options, the .PL should not configure the
module. CPANPLUS would only call the .PL file with those options
(check external prereq) if the yaml indicated there were external
prereqs (backward compatibility).
What you leave out is 'what do we do with these external prereqs that
failed to load' -- you've described a complicated
system to figure out 'it doesnt work', in this case only to please a
few test reports. But it does not address the issue
on how to be able to actually *make it work*, which seems much more
interesting.
external prereq failure of a critical component should cause cpanplus
to bail out of the build. unlike with perl prereqs, there is no
recovery action available to cpanplus.
There is no need for recovery if we can specify the prereq like we do
with regular perl prereqs. Alien could be a solution
for this.
or, the .PL could supply a helper function for recovery action. for
example, in Compress::Bzip2 if there is no bzlib installed, the
recovery action is to activate the static build of the internal bzlib
tagalong. you could go crazy with this one. like if a c compiler is
missing you could fire up some p2p action and download a c compiler
and install it.
This does breach the 'do one thing and do it well' motto quite heavily.
A more generic solution is what's to be preferred,
if we're going through the trouble of altering both EU::MM, M::B,
CPANPLUS and perhaps CPAN.pm -- and since you address
backwards compatibility, it would be even more ideal if we could
abstract this so far away, that none of the tools would
even /need/ altering. Again, i point at Alien for inspiration.
--
Jos Boumans
'Real programmers use "cat > a.out"'
CPANPLUS http://cpanplus.sf.net
