module-build-general — General discussion about Module::Build project

[Module-build-general] MakeMaker Is DOOMED!

[<sc...@po...>]

Tonite at Portland.pm I gave a lightning talk entitled "MakeMaker Is DOOMED!
or MakeMaker Is Dead!  Long Live Module::Build!".

Executive summary:
The architecture of MakeMaker is fundamentally flawed by having to use
an external build tool.  Further feature development is discouraged.
Use Module::Build instead.

Which is what I've been saying all long. :)

http://www.pobox.com/~schwern/talks/MakeMaker_Is_DOOMED/

I'll be giving a somewhat longer version of this at the German Perl Workshop,
pending some financial disputes, talking a lot more about Module::Build and
less about how much I am sick of MakeMaker.

Re: [Module-build-general] Article on perl.com

[<and...@an...>]

>>>>> On Wed, 12 Feb 2003 22:30:04 -0600 (CST), Dave Rolsky <au...@ur...> said:

  > I wrote an article about Module::Build for perl.com, and it's now
  > available at http://www.perl.com/pub/a/2003/02/12/module1.html

Thanks for that article!

Please send me your patch to CPAN.pm that supports Build.PL. I cannot
promise that I can work on it (tuits, tuits!), but I'll at least
consider doing it.

There's one thing that immediately came to my mind but you didn't
discuss it. You write:

    Another possibility is to create functionally equivalent Build.PL
    and Makefile.PL scripts. If you're using Module::Build because you
    need to customize installation behavior in a way that is difficult
    to do with ExtUtils::MakeMaker, this pretty much defeats the
    purpose of using Module::Build at all, and in any case having two
    separate pieces of code that do the same thing is always
    unappealing.

Let's imagine, Module::Build could write an *equivalent* Makefile.PL.
One that could then be used with ExtUtils::MakeMaker (and without
Module::Build). If that were possible (even just for 80% of the
modules out there), that would convince many developers to switch, as
they would just distribute both Build.PL and Makefile.PL (no
duplicated work). The result would not bother anybody among the user
community, as they would not even notice that Module::Build had been
working. For the 20% of complicated modules, Module::Build could just
die() with a few FIXME messages and that might be an incentive to many
a developer to actually produce patches. Maybe I'm missing something,
and surely this has been discussed before, but if you could discuss
this idea, I'd be interested to hear your arguments.

-- 
andreas

[Module-build-general] Article on perl.com

[Dave R. <au...@ur...>]

I wrote an article about Module::Build for perl.com, and it's now
available at http://www.perl.com/pub/a/2003/02/12/module1.html

There will be another sometime in the next few weeks, I hope.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] distsign & sign option

[Dave R. <au...@ur...>]

On Mon, 10 Feb 2003, Ken Williams wrote:

> > After those errors, I get some errors about not having my keyring set
> > up properly, which I don't.  It would be nice if Module::Signature had
> > some methods to probe for this kind of thing, then we could do such
> > probing in the tests.
>
> This is still an issue.

I think this is probably something that should be fixed in
Module::Signature.  Autrijus?


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] distsign & sign option

[Ken W. <ke...@ma...>]

On Monday, February 10, 2003, at 03:27  PM, Ken Williams wrote:
>
> It looks like Module::Signature (version 0.21) is trying to sign in 
> the top-level module directory instead of in the distdir directory.  
> Do you see different behavior?

Okay, I figured I'd just chdir() into the distdir and run distsign from 
there.


> After those errors, I get some errors about not having my keyring set 
> up properly, which I don't.  It would be nice if Module::Signature had 
> some methods to probe for this kind of thing, then we could do such 
> probing in the tests.

This is still an issue.

  -Ken

Re: [Module-build-general] distsign & sign option

[Ken W. <ke...@ma...>]

On Saturday, February 8, 2003, at 04:13  PM, Dave Rolsky wrote:

> At the end of this message is a patch that implements a distsign action
> for Module::Build.  This uses Module::Signature to sign the 
> distribution.
> Additionally, it adds a new property, 'sign', which can be set for a
> distribution.  If true, the distsign action is called whenever dist is
> called.
>
> There are tests as well, but is should be noted that there are two
> potential problems with the test:
>
> 1. If you have Module::Signature, but no keys in your keyring, the 
> tests
> will probably fail.
>
> 2. If you do have keys, you'll be prompted for a passphrase.  I'm not 
> sure
> if this is really desirable behavior for tests run during a module
> install.
>
> Anyway, disabling the tests for non-maintainers would be easy enough.


I've applied these patches to CVS.  There are a couple of problems 
still - when I run the tests, I get these errors:


[junior:~/src/Module-Build] ken% Build test test_files=t/runthrough.t
t/runthrough........ok 10/13Not in MANIFEST: Build
Not in MANIFEST: Sample-0.01/Build.PL
Not in MANIFEST: Sample-0.01/MANIFEST
Not in MANIFEST: Sample-0.01/META.yml
Not in MANIFEST: Sample-0.01/lib/Sample.pm
Not in MANIFEST: Sample-0.01/test.pl
Not in MANIFEST: _build/build_params
Not in MANIFEST: _build/cleanup
Not in MANIFEST: _build/prereqs
Not in MANIFEST: save_out
==> MISMATCHED content between MANIFEST and the distribution! <==
==> Please correct your MANIFEST file and/or delete extra files. <==


It looks like Module::Signature (version 0.21) is trying to sign in the 
top-level module directory instead of in the distdir directory.  Do you 
see different behavior?

After those errors, I get some errors about not having my keyring set 
up properly, which I don't.  It would be nice if Module::Signature had 
some methods to probe for this kind of thing, then we could do such 
probing in the tests.



  -Ken

Re: [Module-build-general] 4th (undocumented) argument to ExtUtils::Install::install

[Ken W. <ke...@ma...>]

On Sunday, February 9, 2003, at 08:48  PM, Dave Rolsky wrote:

> On Sun, 9 Feb 2003, Ken Williams wrote:
>
>>> Are you really sure?  On my system, I copied
>>> /usr/local/share/perl/5.8.0/Module/Build/Base.pm to
>>> /usr/share/perl/5.8.0/Module/Build/Base.pm
>>>
>>> If I then changed Base.pm and did "./Build install uninst=1" it  
>>> worked
>>> fine.
>>
>>
>> Well, it looks like my ExtUtils::Install is broken.  I just did the
>> same thing under MakeMaker and it didn't work there either.  I've got
>> version 1.31 of EU::I installed, which is the same as what's in the
>> EU::MM CVS repository right now.
>
> I have 1.30.  That may explain it.

Either that, or it's allergic to me.  On a different machine with EU::I  
1.28, I get sporadic behavior.  Note the 'ls' at the end of this  
indicating at least one shadow file that should have been removed, but  
only a couple of shadows were actually removed.

======================================================================== 
==
[www:~/src/AI-Categorizer] ken> perl Build.PL  
config='sitearch=/home/ken/lib/i386-linux'
  .... build and test ...
[www:~/src/AI-Categorizer] ken> Build install uninst=1
Useless use of a variable in void context at  
/usr/lib/perl5/5.6.1/ExtUtils/Install.pm line 267.
Warning: You do not have permissions to install into  
/usr/lib/perl5/site_perl/5.6.1 at  
/usr/lib/perl5/5.6.1/ExtUtils/Install.pm line 85.
Installing  
/home/ken/lib/i386-linux/auto/AI/Categorizer/FeatureVector/FastDot/ 
FastDot.bs
Installing  
/home/ken/lib/i386-linux/auto/AI/Categorizer/FeatureVector/FastDot/ 
FastDot.so
Files found in blib/arch: installing files in blib/lib into  
architecture dependent library tree
Installing /home/ken/lib/i386-linux/AI/Categorizer.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Category.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Collection.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Document.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Experiment.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/FeatureSelector.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/FeatureVector.pm
Unlinking /home/ken/lib/AI/Categorizer/FeatureVector.pm (shadowing?)
Installing /home/ken/lib/i386-linux/AI/Categorizer/Hypothesis.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/KnowledgeSet.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Learner.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/ObjectSet.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Storable.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Util.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Collection/Files.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Collection/DBI.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Collection/DBI2.pm
Installing  
/home/ken/lib/i386-linux/AI/Categorizer/Collection/InMemory.pm
Installing  
/home/ken/lib/i386-linux/AI/Categorizer/Collection/SingleFile.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Document/SMART.pm
Installing  
/home/ken/lib/i386-linux/AI/Categorizer/Document/ScoredFeatures.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Document/Text.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Document/XML.pm
Installing  
/home/ken/lib/i386-linux/AI/Categorizer/FeatureSelector/DocFrequency.pm
Installing  
/home/ken/lib/i386-linux/AI/Categorizer/FeatureVector/FastDot.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Learner/Boolean.pm
Unlinking /home/ken/lib/AI/Categorizer/Learner/Boolean.pm (shadowing?)
Installing  
/home/ken/lib/i386-linux/AI/Categorizer/Learner/DecisionTree.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Learner/Guesser.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Learner/KNN.pm
Unlinking /home/ken/lib/AI/Categorizer/Learner/KNN.pm (shadowing?)
Installing /home/ken/lib/i386-linux/AI/Categorizer/Learner/NNetTC.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Learner/NaiveBayes.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Learner/Rocchio.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Learner/SVM.pm
Installing /home/ken/lib/i386-linux/AI/Categorizer/Learner/Weka.pm
[www:~/src/AI-Categorizer] ken> ls ~/lib/AI
Categorizer/  Categorizer.pm
[www:~/src/AI-Categorizer] ken> perl -MExtUtils::Install -le 'print  
$ExtUtils::Install::VERSION'
1.28
======================================================================== 
==

  -Ken

Re: [Module-build-general] 4th (undocumented) argument to ExtUtils::Install::install

[Dave R. <au...@ur...>]

On Sun, 9 Feb 2003, Ken Williams wrote:

> > Are you really sure?  On my system, I copied
> > /usr/local/share/perl/5.8.0/Module/Build/Base.pm to
> > /usr/share/perl/5.8.0/Module/Build/Base.pm
> >
> > If I then changed Base.pm and did "./Build install uninst=1" it worked
> > fine.
>
>
> Well, it looks like my ExtUtils::Install is broken.  I just did the
> same thing under MakeMaker and it didn't work there either.  I've got
> version 1.31 of EU::I installed, which is the same as what's in the
> EU::MM CVS repository right now.

I have 1.30.  That may explain it.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] 4th (undocumented) argument to ExtUtils::Install::install

[Ken W. <ke...@ma...>]

On Sunday, February 9, 2003, at 10:46  AM, Dave Rolsky wrote:

> On Sun, 9 Feb 2003, Ken Williams wrote:
>
>>> It'll only unlink a shadowing file _if and only if_ it is installing 
>>> a
>>> new
>>> file.  So if you just run "./Build install uninst=1" and nothing has
>>> changed, then nothing gets unlinked.
>>>
>>> I don't know if this is correct, but that's the deal ;)
>>
>> Yeah, but in my case that's what was happening, and it still didn't
>> unlink 'em.
>
> Are you really sure?  On my system, I copied
> /usr/local/share/perl/5.8.0/Module/Build/Base.pm to
> /usr/share/perl/5.8.0/Module/Build/Base.pm
>
> If I then changed Base.pm and did "./Build install uninst=1" it worked
> fine.


Well, it looks like my ExtUtils::Install is broken.  I just did the 
same thing under MakeMaker and it didn't work there either.  I've got 
version 1.31 of EU::I installed, which is the same as what's in the 
EU::MM CVS repository right now.


  -Ken

Re: [Module-build-general] 4th (undocumented) argument to ExtUtils::Install::install

[Dave R. <au...@ur...>]

On Sun, 9 Feb 2003, Ken Williams wrote:

> > It'll only unlink a shadowing file _if and only if_ it is installing a
> > new
> > file.  So if you just run "./Build install uninst=1" and nothing has
> > changed, then nothing gets unlinked.
> >
> > I don't know if this is correct, but that's the deal ;)
>
> Yeah, but in my case that's what was happening, and it still didn't
> unlink 'em.

Are you really sure?  On my system, I copied
/usr/local/share/perl/5.8.0/Module/Build/Base.pm to
/usr/share/perl/5.8.0/Module/Build/Base.pm

If I then changed Base.pm and did "./Build install uninst=1" it worked
fine.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] 4th (undocumented) argument to ExtUtils::Install::install

[Ken W. <ke...@ma...>]

On Sunday, February 9, 2003, at 10:31  AM, Dave Rolsky wrote:

> It'll only unlink a shadowing file _if and only if_ it is installing a 
> new
> file.  So if you just run "./Build install uninst=1" and nothing has
> changed, then nothing gets unlinked.
>
> I don't know if this is correct, but that's the deal ;)

Yeah, but in my case that's what was happening, and it still didn't 
unlink 'em.


> Also, for extra fun, note that EU::Install prints messages like this:
>
> ## Running 'make install UNINST=1' will unlink $plural for you.\n
>
> direct to STDOUT.  It'd be nice to catch that and rewrite it in M::B
> language, but what an annoying PITA.

Indeed.

  -Ken

Re: [Module-build-general] 4th (undocumented) argument to ExtUtils::Install::install

[Dave R. <au...@ur...>]

On Sun, 9 Feb 2003, Ken Williams wrote:

> So, I made this change in the M::B code, and it didn't seem to produce
> the desired effect:
>
> ------------------------------------------------------------------------
> --------
> sub ACTION_install {
>    my ($self) = @_;
>    require ExtUtils::Install;
>    $self->depends_on('build');
>    ExtUtils::Install::install($self->install_map('blib'), 1, 0,
> $self->{args}{uninst}||0);
> }
>
> sub ACTION_fakeinstall {
>    my ($self) = @_;
>    require ExtUtils::Install;
>    $self->depends_on('build');
>    ExtUtils::Install::install($self->install_map('blib'), 1, 1,
> $self->{args}{uninst}||0);
> }
> ------------------------------------------------------------------------
> --------
>
> Doing a 'Build install uninst=1' didn't unlink the ghosties.  I don't
> have time to check into it right now though, because I'm busily at work
> trying to make some headway on my soon-due thesis.  Any idea why this
> wouldn't work?

It'll only unlink a shadowing file _if and only if_ it is installing a new
file.  So if you just run "./Build install uninst=1" and nothing has
changed, then nothing gets unlinked.

I don't know if this is correct, but that's the deal ;)

Also, for extra fun, note that EU::Install prints messages like this:

## Running 'make install UNINST=1' will unlink $plural for you.\n

direct to STDOUT.  It'd be nice to catch that and rewrite it in M::B
language, but what an annoying PITA.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] 4th (undocumented) argument to ExtUtils::Install::install

[Ken W. <ke...@ma...>]

On Monday, February 3, 2003, at 09:21  PM, Dave Rolsky wrote:
> There's a 4th, very important, but completely undocumented argument to
> ExtUtils::Install.  This is a flag that tells it to unlink "shadowing"
> files, and is how the "perl Makefile.PL UNINST=1" feature is  
> implemented.
>
> Knowing this flag exists makes implementing this feature in  
> Module::Build
> very easy.  It also makes me _VERY DAMN IRRITATED_, but I was _already_
> irritated about the general state of the legacy Perl build system, so  
> that
> changes nothing ;)


So, I made this change in the M::B code, and it didn't seem to produce  
the desired effect:

------------------------------------------------------------------------ 
--------
sub ACTION_install {
   my ($self) = @_;
   require ExtUtils::Install;
   $self->depends_on('build');
   ExtUtils::Install::install($self->install_map('blib'), 1, 0,  
$self->{args}{uninst}||0);
}

sub ACTION_fakeinstall {
   my ($self) = @_;
   require ExtUtils::Install;
   $self->depends_on('build');
   ExtUtils::Install::install($self->install_map('blib'), 1, 1,  
$self->{args}{uninst}||0);
}
------------------------------------------------------------------------ 
--------

Doing a 'Build install uninst=1' didn't unlink the ghosties.  I don't  
have time to check into it right now though, because I'm busily at work  
trying to make some headway on my soon-due thesis.  Any idea why this  
wouldn't work?

  -Ken

[Module-build-general] distsign & sign option

[Dave R. <au...@ur...>]

At the end of this message is a patch that implements a distsign action
for Module::Build.  This uses Module::Signature to sign the distribution.
Additionally, it adds a new property, 'sign', which can be set for a
distribution.  If true, the distsign action is called whenever dist is
called.

There are tests as well, but is should be noted that there are two
potential problems with the test:

1. If you have Module::Signature, but no keys in your keyring, the tests
will probably fail.

2. If you do have keys, you'll be prompted for a passphrase.  I'm not sure
if this is really desirable behavior for tests run during a module
install.

Anyway, disabling the tests for non-maintainers would be easy enough.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/


Only in .: SIGNATURE
diff -ru ../Module-Build/lib/Module/Build/Base.pm ./lib/Module/Build/Base.pm
--- ../Module-Build/lib/Module/Build/Base.pm	2003-01-21 00:38:18.000000000 -0600
+++ ./lib/Module/Build/Base.pm	2003-02-08 18:08:23.000000000 -0600
@@ -777,6 +777,7 @@
 sub ACTION_dist {
   my ($self) = @_;

+  $self->depends_on('distsign') if $self->{properties}{sign};
   $self->depends_on('distdir');

   my $dist_dir = $self->dist_dir;
@@ -825,6 +826,18 @@
   warn "*** Did you forget to add $metafile to the MANIFEST?\n" unless exists $dist_files->{$metafile};
 }

+sub ACTION_distsign {
+  my ($self) = @_;
+
+  eval { require Module::Signature };
+  if ($@) {
+    warn "*** The distsign action requires that Module::Signature be installed in order to work.\n";
+    return;
+  }
+
+  Module::Signature::sign();
+}
+
 sub ACTION_disttest {
   my ($self) = @_;

diff -ru ../Module-Build/lib/Module/Build.pm ./lib/Module/Build.pm
--- ../Module-Build/lib/Module/Build.pm	2003-01-21 00:38:18.000000000 -0600
+++ ./lib/Module/Build.pm	2003-02-08 18:09:51.000000000 -0600
@@ -381,6 +381,12 @@
 something useful with it.  It can potentially bring lots of security,
 packaging, and convenience improvements.

+=item sign
+
+A boolean flag indicating whether a distribution should always be
+signed.  If this is true, then running the "dist" action will run the
+"distsign" action before "dist".  The default value is 0.
+
 =back

 =item create_build_script()
@@ -765,6 +771,11 @@
 tarball of the files listed in F<MANIFEST> and compress the tarball using
 GZIP compression.

+=item distsign
+
+Uses Module::Signature to create a SIGNATURE file for your
+distribution.
+
 =item distcheck

 Reports which files are in the build directory but not in the
diff -ru ../Module-Build/t/runthrough.t ./t/runthrough.t
--- ../Module-Build/t/runthrough.t	2002-12-30 19:05:12.000000000 -0600
+++ ./t/runthrough.t	2003-02-08 18:03:58.000000000 -0600
@@ -4,6 +4,7 @@
 use File::Spec;
 use File::Path;
 my $HAVE_YAML = eval {require YAML; 1};
+my $HAVE_MS = eval {require Module::Signature; 1};

 ok(1);
 require File::Spec->catfile('t', 'common.pl');
@@ -62,6 +63,15 @@
   skip "skip YAML.pm is not installed", 1 for 1..6;
 }

+if ($HAVE_MS) {
+  eval {$build->dispatch('distsign')};
+  ok $@, '';
+
+  ok -e File::Spec->catdir('Sample-0.01', 'SIGNATURE');
+} else {
+  skip "skip Module::Signature is not installed", 1 for 1..2;
+}
+
 eval {$build->dispatch('realclean')};
 ok $@, '';

Re: [Module-build-general] EU::ParseXS & M::B

[Ken W. <ke...@ma...>]

On Wednesday, February 5, 2003, at 09:44  AM, Dave Rolsky wrote:
> Module::Build has a prereq on EU::ParseXS, but since EU::ParseXS is 
> only
> on CPAN as a dev release, the CPAN shell can't install it.  Might as 
> well
> release a real EU::ParseXS.

Good point.  I think this bit Dan Sugalski recently too.

  -Ken

[Module-build-general] EU::ParseXS & M::B

[Dave R. <au...@ur...>]

Module::Build has a prereq on EU::ParseXS, but since EU::ParseXS is only
on CPAN as a dev release, the CPAN shell can't install it.  Might as well
release a real EU::ParseXS.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] Some improvement to the pass-thru compat Makefile.PL

[Dave R. <au...@ur...>]

On Wed, 5 Feb 2003, Autrijus Tang wrote:

> > Autrijus, what exactly is this checking?  Is it just that the "index"
> > check returns -1 only for certain newer versions of CPAN.pm?
>
> Mmm? CPAN.pm is non-reentrant in general, so we cannot use it if we're
> under CPAN.pm's installation already.  The check is to see that our
> cwd() is not under .cpan/.

I'm pretty sure it is re-entrant, at least the version I'm using.  To test
this I just deleted my local copies of Module/Build.pm and
Module/Build/Compat.pm, as well as Thesaurus.pm.  I then installed
Thesaurus.pm from the CPAN shell.  Thesaurus.pm has a passthrough
Makefile.PL, and it all worked just fine.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] Some improvement to the pass-thru compat Makefile.PL

[Autrijus T. <aut...@au...>]

On Mon, Feb 03, 2003 at 05:25:02PM -0600, Dave Rolsky wrote:
> On Thu, 19 Dec 2002, Autrijus Tang wrote:
>=20
> >         # Check if we're under the non-reentrant CPAN.pm
> >         require CPAN;
> >         CPAN::Config->load;
> >
> >         my $cwd  =3D File::Spec->canonpath(Cwd::cwd());
> >         my $cpan =3D File::Spec->canonpath($CPAN::Config->{cpan_home});
> >         if (index($cwd, $cpan) =3D=3D -1) {
> >             print "This module requires Module::Build to install itself=
.\n";
> >
> >             $yn =3D ExtUtils::MakeMaker::prompt(
> >                 '  Install Module::Build from CPAN?', 'y'
> >             );
> >         }
>=20
> Autrijus, what exactly is this checking?  Is it just that the "index"
> check returns -1 only for certain newer versions of CPAN.pm?

Mmm? CPAN.pm is non-reentrant in general, so we cannot use it if we're
under CPAN.pm's installation already.  The check is to see that our
cwd() is not under .cpan/.

> And shouldn't this check come _after_ checking for CPANPLUS?

No... Since the only condition our autoinstallation will fail is under
CPAN.pm; CPANPLUS plays well re-entrantly.

/Autrijus/

[Module-build-general] 4th (undocumented) argument to ExtUtils::Install::install

[Dave R. <au...@ur...>]

There's a 4th, very important, but completely undocumented argument to
ExtUtils::Install.  This is a flag that tells it to unlink "shadowing"
files, and is how the "perl Makefile.PL UNINST=1" feature is implemented.

Knowing this flag exists makes implementing this feature in Module::Build
very easy.  It also makes me _VERY DAMN IRRITATED_, but I was _already_
irritated about the general state of the legacy Perl build system, so that
changes nothing ;)


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] conflicts and test_requires

[Dave R. <au...@ur...>]

On Mon, 3 Feb 2003, Ken Williams wrote:

>
> On Monday, February 3, 2003, at 01:25  PM, Dave Rolsky wrote:
> > There probably needs to be a command line flag to ignore conflicts, or
> > else a module that specifies conflicts could be entirely uninstallable.
>
> What do you mean by "uninstallable"?  The 'conflicts' entries should
> really just generate a warning/error that can be ignored if installing
> by hand, so I'm not sure a special flag is necessary.

Well, I was thinking that something CPANPLUS should respect conflicts but
there'd be a way to override it.  I guess this doesn't need to be in
Module::Build itself.

>
> > Also, was there discussion about a "test_requires" option, so that
> > tests could be skipped if certain modules weren't installed?  Seems
> > like a useful option.
>
> I don't remember such a discussion - I've been thinking of this as the
> primary reason someone might want to put something in the
> "build_requires" field, since typically the actual *building* doesn't
> require any special tools.  But I suppose sometimes it does, like if
> some C library is statically compiled into the module's loadable parts.
>
> Do you think it would be very useful to split test_requires off from
> build_requires?  I'm inclined to leave them as one field, emphasizing
> that testing should usually be a part of the build process.

Well, I was thinking that someone might want to get a "pre-build" module
(whatever that means) and still run the tests.

Also, someone may want to build and install the module but doesn't care if
the tests run.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] conflicts and test_requires

[Ken W. <ke...@ma...>]

On Monday, February 3, 2003, at 01:25  PM, Dave Rolsky wrote:
> There probably needs to be a command line flag to ignore conflicts, or
> else a module that specifies conflicts could be entirely uninstallable.

What do you mean by "uninstallable"?  The 'conflicts' entries should 
really just generate a warning/error that can be ignored if installing 
by hand, so I'm not sure a special flag is necessary.


> Also, was there discussion about a "test_requires" option, so that 
> tests
> could be skipped if certain modules weren't installed?  Seems like a
> useful option.

I don't remember such a discussion - I've been thinking of this as the 
primary reason someone might want to put something in the 
"build_requires" field, since typically the actual *building* doesn't 
require any special tools.  But I suppose sometimes it does, like if 
some C library is statically compiled into the module's loadable parts.

Do you think it would be very useful to split test_requires off from 
build_requires?  I'm inclined to leave them as one field, emphasizing 
that testing should usually be a part of the build process.

  -Ken

Re: [Module-build-general] archives

[Dave R. <au...@ur...>]

On Mon, 3 Feb 2003, Ken Williams wrote:

>
> On Monday, February 3, 2003, at 02:42  PM, Dave Rolsky wrote:
> > There's no archives for this list.  Ken, can you turn on the SF archive
> > feature?  Of course, the SF archives suck, so it'd be nice to be added
> > to
> > nntp.x.perl and archive.develooper.com (the reason I'm cc'ing Ask ;)
>
> It's already being archived at
>
>   http://sourceforge.net/mailarchive/forum.php?forum_id=10905
>   i.e. http://sf.net/projects/module-build -> Lists -> Archive
>
> And yeah, they suck, but it might remain both The Path of Least
> Resistance and The Easiest Place for People to Find.

When I looked earlier it said "archives unavailable", I thought it meant
that they hadn't been turned on, but it seems to have been some SF
maintenance thing.

And the archives do suck, cause they aren't searchable.  Ick!


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] archives

[Ken W. <ke...@ma...>]

On Monday, February 3, 2003, at 02:42  PM, Dave Rolsky wrote:
> There's no archives for this list.  Ken, can you turn on the SF archive
> feature?  Of course, the SF archives suck, so it'd be nice to be added 
> to
> nntp.x.perl and archive.develooper.com (the reason I'm cc'ing Ask ;)

It's already being archived at

  http://sourceforge.net/mailarchive/forum.php?forum_id=10905
  i.e. http://sf.net/projects/module-build -> Lists -> Archive

And yeah, they suck, but it might remain both The Path of Least 
Resistance and The Easiest Place for People to Find.

  -Ken

[Module-build-general] Re: archives

[Ask B. H. <as...@pe...>]

On Mon, 3 Feb 2003, Dave Rolsky wrote:

> There's no archives for this list.  Ken, can you turn on the SF archive
> feature?  Of course, the SF archives suck, so it'd be nice to be added to
> nntp.x.perl and archive.develooper.com (the reason I'm cc'ing Ask ;)

Can only make archives if we host the list.


 - ask

-- 
ask bjoern hansen, http://askbjoernhansen.com/  !try;
develooper llc,    http://www.develooper.com/   do();

Re: [Module-build-general] Some improvement to the pass-thru compat Makefile.PL

[Dave R. <au...@ur...>]

On Thu, 19 Dec 2002, Autrijus Tang wrote:

>         # Check if we're under the non-reentrant CPAN.pm
>         require CPAN;
>         CPAN::Config->load;
>
>         my $cwd  = File::Spec->canonpath(Cwd::cwd());
>         my $cpan = File::Spec->canonpath($CPAN::Config->{cpan_home});
>         if (index($cwd, $cpan) == -1) {
>             print "This module requires Module::Build to install itself.\n";
>
>             $yn = ExtUtils::MakeMaker::prompt(
>                 '  Install Module::Build from CPAN?', 'y'
>             );
>         }

Autrijus, what exactly is this checking?  Is it just that the "index"
check returns -1 only for certain newer versions of CPAN.pm?  And
shouldn't this check come _after_ checking for CPANPLUS?


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/