On 26/11/02 07:17 -0800, David Wheeler wrote:
> On Tuesday, November 26, 2002, at 07:00 AM, Graham Barr wrote:
>
> > On Tue, Nov 26, 2002 at 10:51:10AM +0000, Matt Sergeant wrote:
> >> On Mon, 25 Nov 2002, Graham Barr wrote:
> >>
> >>> If the inclusion of modules in distributions is common and t/ is
> >>> not acceptable then a common place should be agreeded. I almost
> >>> suggested this recently with the release of CPAN::MakeMaker which
> >>> depends on . being in @INC. But it has the side affect that
> >>> everyone will have CPAN::MakeMaker in thier dist on search.
I had forgot that Search goes through the entire tarball looking for .pm
files. EU::MakeMaker doesn't do this. It only uses modules in ./ lib/ or
contiguous subdirectories containing a Makefile.PL. I found this out when I
tried to hide a sample Math::Simple in the Inline dist. It doesn't get
installed, but it gets (much to my chagrin) indexed.
It would be nice to prevent this.
> >> I copied POE when I added ExtUtils::AutoInstall and put in in
> >> install/ to some of my modules. I think that's as good a place as
> >> any. Alternatively you could use a dot-dir.
> >
> > A dot-dir is not very portable. At first I like the name install/
> > but then it dawned on me that it is very common for installations to
> > have a file called INSTALL, so a directory called install would not
> > work too well on platforms that are case insensetive (DOS, Mac OS).
> > Unfortunately this same argument goes against similar names like
> > build. So I dont have any better suggestion other than something
> > like privlib.
>
> What does CPAN::MakeMaker want to use?
Well I am trying to stick everything sneaky under the ./CPAN/ directory.
Since that directory must be there for CPAN::MakeMaker to work anyway.
It's interesting that I couldn't have used the module name
CPAN_MakeMaker.pm because it would have been picked up for installation;
but since MakeMaker.pm is under ./CPAN/ , EU::MM ignores it. (Search
should too :)
CPAN::MakeMaker has one very enticing feature, and that is the fact that
I can change the API at will. If a feature isn't popular or is clunky, I
don't need to support it in the next version. And when a bug is found,
only the author needs to upgrade. That's because CP::MM doesn't get
installed. It's really just a modular extension of one's Makefile.PL.
But one thing I hadn't thought about was the impact to Search and
friends. I need to have API's that support the defacto "standards", so
that the search database doesn't get inadvertantly muddied. At least
not too much.
Here is a first cut at a bundling interface:
use CPAN::MakeMaker qw(:bundle);
$NAME = 'Foo::Bar';
$AUTHOR = 'Kung Fu';
$ABSTRACT = 'Your typical foo';
bundle('mybundles/Bot-Pluggable-0.02.tar.gz');
bundle('./YAML-0.35.tar.gz', 'YAML::Node', '0.28');
bundle_module('My::Module');
include_Test_More;
@CLEAN_FILES = qw(t/temp xxx*);
WriteMakefile;
This is the basics of a CPAN::MakeMaker Makefile.PL in its current
development path. WriteMakefile keywords can still be used (for EU::MM
functionality), but I prefer the cleaner global variable and simple
function approach for new CP::MM functionality.
In this example, the first bundle() assumes that there is only one
module in the dist. The second example explicitly states the prereq
condition. The third one pulls a single module right out of @INC and
will probably stick it under './CPAN/bundle/My/Module.pm'. The
include_Test_More, includes the author's version of Test::More; not for
installation, but simply for support.
As you can see, bundle tarballs can go anywhere. This probably won't confuse
Search, since they are tarred up. The bundle_module stuff goes under CPAN/. I
would suggest ignoring ./CPAN/ for modules. (Does anyone use ./CPAN/?) The
Test::More stuff could also go under ./CPAN/ and I could adjust the Makefile
to put ./CPAN/ in the @INC path.
The upshot would (could) be that CPAN::MakeMaker reserves ./CPAN for itself.
It should be easy to detect if the Author was trying to use it for anything
else, and give a fair warning.
Cheers, Brian
