GNOME Bugzilla – Bug 342638
support for building CPAN modules
Last modified: 2006-06-19 05:15:52 UTC
system-tools-backends now depends upon Net::DBus; this requires jhbuild to support CPAN modules.
The attached patch adds preliminary support, since I am no Perl user I'm not that sure everything is done according to the rules, I looked into dh-make-perl to get an idea of common steps.
Ideally it would have been great just to have to add Net::DBus to moduleset and have Perl CPAN support do most of the work but I couldn't get it to isolate steps; I kept a note about this ideal support but added a <source> tag identical to the one in <tarball>; see:
<module name="Net::DBus" /> <!-- XXX: this would be ideal -->
I can commit this whenever I get my account and you are happy with the patch.
Created attachment 66025 [details] [review]
Jhbuild CPAN support
Two immediate issues:
(1) is CPAN the right name for this? Would the Perl make infrastructure usually be described as "CPAN" when not using the CPAN shell to build stuff?
(2) rather than copying the Tarball module type, it would be better to copy the Autotools module type. There is a tarball versioncontrol backend that will handle tarball builds, and this would also allow the module type to work with CVS, Subversion, Darcs and GIT with no additional coding.
The <module> sub-element seems superfluous. In your patch the module_name doesn't seem to get used at all. Is it actually needed?
If you base the module type on <autotools>, the XML for it might look something like this:
<repository type="tarball" name="cpan" href="http://search.cpan.org/CPAN/" />
(this also lets people override the repository URL to pick a different CPAN mirror).
CPAN was the right name at the start, when I thought I could use Perl CPAN module/command to get this working, module_name and the associated tag is a remnant of that era.
History pushed aside <perl> might be better than <cpan>; I'll work on a patch implementing your comments this evening.
Created attachment 66084 [details] [review]
This implements Perl module support as outlined in your comment; also PerlModule class inherits from AutogenModule to avoid code duplication.
I've committed a modified version of your patch to bzr and merged to CVS.
Rather than trying to shoehorn PerlModule in as a subclass of AutogenModule, it is now a direct subclass of Package. This simplifies things a bit.
I also updated the module to the new state skipping framework, which simplifies the logic a bit.