>
> Regardless of whether this is a cpantester problem or a cpan problem,
> adding
> $ENV{'PERL5'} = $^X;
It looks like there *is* code to set PERL (not PERL5 as above, but that's
fine). However I don't believe it is not set before running a plain "make"
or "make test". So I've created a github pull request
<https://github.com/andk/cpanpm/pull/100>for that and we can take
discussion of over to github.
Also in that pull request is adding "-f Makefile" at least on the initial
"make" (no args). I tried adding to "make install" as well, but a test
fails when I did that.
On Sat, Jul 2, 2016 at 8:13 PM, Rocky Bernstein <rocky.bernst...@gmail.com>
wrote:
> > Remove the GNUMakefile and I believe everything will work as intended.
>
> I can do that and that will probably work. But I like and use that
> GNUMakefile. That's why I wrote it. Also, doesn't this feel a little bit
> contrary to the Perl philosophy of "there's more than one way to do it" and
> more like Python's: we've decided for you how you should do it.
>
> If there is a problem in the technology, why not fix the technology rather
> than limit what can be done?
>
> And so I've been puzzling over with whether this a problem that people
> using cpan or cpanm will notice or is it just a cpantester issue? Right now
> it feels like a problem in the smoker software or setup, although there
> might be changes to cpan or cpanm that might assist.
>
> So here's what I tried. On my computer I have perlbrew that can be
> optionally set up. So without it in my path, that is my perl path is the OS
> system perl, I then ran the perlbew cpan binary. I made sure that
> Module::Build wasn't available in the system perl. Running cpan, it
> downloaded the package and tested fine. Elided details are at the end of
> this message.
>
> Regardless of whether this is a cpantester problem or a cpan problem,
> adding
>
> $ENV{'PERL5'} = $^X;
>
> In the right place doesn't seem too cumbersome. Adding to the PATH is a
> little more involved since there are OS issues to worry about. But that
> probably isn't hard to do either.
>
> And there's another problem as I see it.
>
> If cpan or cpanm is running something like:
>
> system("$^X Makefile.PL"); system("make t-test") unless $?>>8;
>
> this could be improved. Extutils creates a file called "Makefile", not "
> GNUMakefile". However "make t-test" is letting the "make" system decide
> what Makefile file to use. So more reliable and secure would be to run
> system("make -f Makefile t-test").
>
> The "-f" option is in fact part of POSIX Make
> <http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html>.
>
>
> Here are the details of my test. If folks can figure out a way to make
> cpan or cpanm fail independent of cpantesters I'd be interested to learn
> about.
>
> perl -MModule::Build -e 1
> Can't locate Module/Build.pm in @INC (you may need to install the
> Module::Build module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2
> /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5
> /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .).
> BEGIN failed--compilation aborted.
> $ /home/rocky/perl5/perlbrew/perls/perl-5.22.0/bin/cpan Bio::BPWrapper
> Loading internal null logger. Install Log::Log4perl for logging messages
> CPAN: Storable loaded ok (v2.53)
> ...
> Configuring R/RO/ROCKY/Bio-BPWrapper-1.11.tar.gz with Build.PL
> Created MYMETA.yml and MYMETA.json
> Creating new 'Build' script for 'Bio-BPWrapper' version '1.11'
> ROCKY/Bio-BPWrapper-1.11.tar.gz
> /home/rocky/perl5/perlbrew/perls/perl-5.22.0/bin/perl Build.PL
> --installdirs site -- OK
> Running Build for R/RO/ROCKY/Bio-BPWrapper-1.11.tar.gz
> Building Bio-BPWrapper
> ROCKY/Bio-BPWrapper-1.11.tar.gz
> ./Build -- OK
> Running Build test
> t/00test-pod.t ...... ok
> ...
>
>
>
>
>
> On Sat, Jul 2, 2016 at 8:39 AM, Chris 'BinGOs' Williams <
> ch...@bingosnet.co.uk> wrote:
>
>> On Sat, Jul 02, 2016 at 12:16:21AM -0400, Rocky Bernstein wrote:
>> > - shipping both a Makefile.PL and a Build.PL correctly is a tough
>> > problem
>> >
>> >
>> > Although I that I was using the deprecated "passthrough" style, using
>> every
>> > combination listed in the docs a Makefile.PL was added to distribution
>> tarball.
>> > I even tried omitting a line like "create_makefile_pl => 'traditional' .
>> >
>> > Although shipping both a Makefile.PL and a Build.PL may be a tough
>> problem,
>> > having the program that invoke "make test" could set an environment
>> variable
>> > such as PERL. And that would help the makefile and any scripts it runs
>> to use
>> > the right perl.
>> >
>>
>> Having just tested your distribution on GNU/Linux I observed the
>> following:
>>
>> Running perl Build.PL, generates a Build script and everything is good.
>> Running perl Makefile.PL generates a Makefile, which is looks okay, but as
>> GNU Make is being used it seems to favour the GNUMakefile.
>>
>> Remove the GNUMakefile and I believe everything will work as intended.
>>
>> Cheers,
>>
>> --
>> Chris Williams
>> aka BinGOs
>> PGP ID 0x4658671F
>> http://www.gumbynet.org.uk
>> ==========================
>>
>
>
