headers
Eric Wilhelm | 3 Sep 2007 10:13
Picon

Re: r9906 - t/lib/DistGen.pm

# from ericwilhelm <at> cvs.perl.org
# on Monday 03 September 2007 01:10 am:

>t/lib/DistGen.pm - added undent(),
>                   indent heredocs for readability

Hey look!  `perldoc t/lib/DistGen.pm` actually works now.

--Eric
--

-- 
Turns out the optimal technique is to put it in reverse and gun it.
--Steven Squyres (on challenges in interplanetary robot navigation)
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------
Permalink | Reply | 0 comments |
headers
Eric Wilhelm | 3 Sep 2007 21:50
Picon

"no time machine needed" Build.PL

What if the Build.PL which gets shipped with the tarball is 
autogenerated from some kind of "modern"[1] input specification?

In other words, "what you have to type" in *your* Build.PL is not 
dictated by backwards compatibility and certain things can be implied 
or set automatically if the *deployed* Build.PL can be autogenerated.  
Thus, whatever ugly bits might be required for compatibility don't have 
to be hand-written (and documented (and then explained (and, of course, 
still not quite understood by all.)))

That is, you don't have to put Module::Build in the 'requires' key, 
build_requires could be dynamically determined by the available version 
(on the client) of Module::Build, etc.

Yes, there are details[3].  At the moment, it's just a thought about how 
to get compatibility and etc without excessive typing (and without the 
need for special knowledge about various oddities and/or history.)

[1] Where "modern" means simply that it is able to change (even in 
backwards-incompatible ways in some cases[1a]) independently of 
whatever historical accidents.  This implies that it is more active 
than simply feeding a data-structure to new() and/or having arbitrary 
code on either side of that.

[1a] I think incompatibilities would typically be of the "allowed 
omission" type.  For example, there is no [2] :-)

[3] Starting with perhaps the turing trouble -- to dual-life Build.PL, 
the master copy would probably have to be broken down into composeable, 
declared pieces ala something like our_require($mod), our_do($file),
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael G Schwern | 5 Sep 2007 03:00
Picon
Favicon
Gravatar

Module::Build and test.pl (was Re: Machine readable test summary)

David Golden wrote:
> On 9/4/07, Andy Armstrong <andy <at> hexten.net> wrote:
>> As a matter of interest David did you find the exit code from make
>> test to be an unreliable indication of passed / failed? I'm working
>> on running tests for Test::SmokeStack so I'm interested to know if
>> there are any pitfalls in trusting the exit code.
> 
> I'd have to check my test cases.  I think the nasty edge cases involve
> test.pl and the fact that EU::MM and M::B treat it differently.
> EU::MM runs test.pl directly and takes its exit code as success or
> failure.  M::B passes test.pl to Test::Harness and gets that result
> back.

FWIW  Module::Build, IMO, should not be doing that.  It should be doing what
MakeMaker does.  test.pl is highly discouraged so there's no point in making a
Makemaker / Module::Build incompatibility over it.

Anyone still using test.pl with Module::Build should be hit with a hammer anyway.

--

-- 
Stabbing you in the face for your own good.
Permalink | Reply | 3 comments |
headers
David E. Wheeler | 5 Sep 2007 20:37
Gravatar

Re: Module::Build and test.pl (was Re: Machine readable test summary)

On Sep 4, 2007, at 18:00, Michael G Schwern wrote:

> Anyone still using test.pl with Module::Build should be hit with a  
> hammer anyway.

*cough*DBI*cough*

Yeah, okay, it doesn't use Module::Build yet, but it has a very  
specific reason for supporting test.pl in addition to t/. How should  
that sort of thing be handled with M::B?

Best,

David
Permalink | Reply | 1 comment |
headers
Ken Williams | 6 Sep 2007 04:08
Picon
Gravatar

Re: Module::Build and test.pl (was Re: Machine readable test summary)


On Sep 4, 2007, at 8:00 PM, Michael G Schwern wrote:

> David Golden wrote:
>> On 9/4/07, Andy Armstrong <andy <at> hexten.net> wrote:
>>> As a matter of interest David did you find the exit code from make
>>> test to be an unreliable indication of passed / failed? I'm working
>>> on running tests for Test::SmokeStack so I'm interested to know if
>>> there are any pitfalls in trusting the exit code.
>>
>> I'd have to check my test cases.  I think the nasty edge cases  
>> involve
>> test.pl and the fact that EU::MM and M::B treat it differently.
>> EU::MM runs test.pl directly and takes its exit code as success or
>> failure.  M::B passes test.pl to Test::Harness and gets that result
>> back.
>
> FWIW  Module::Build, IMO, should not be doing that.

M::B has been doing that for over 6 years though.  6 years ago I must  
have reasoned that using 2 different mechanisms for running tests  
just because the tests are sitting in different places wasn't ideal.   
And made unnecessary burdens for people trying to transition from  
test.pl to t/*.t .  So I just unified them.

At this point I don't think it would be wise to change it.

  -Ken
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael G Schwern | 6 Sep 2007 04:11
Picon
Favicon
Gravatar

Re: Module::Build and test.pl (was Re: Machine readable test summary)

David E. Wheeler wrote:
> On Sep 4, 2007, at 18:00, Michael G Schwern wrote:
> 
>> Anyone still using test.pl with Module::Build should be hit with a
>> hammer anyway.
> 
> *cough*DBI*cough*
>
> Yeah, okay, it doesn't use Module::Build yet, but it has a very specific
> reason for supporting test.pl in addition to t/. How should that sort of
> thing be handled with M::B?

Same way MakeMaker does:  Do no parsing or capture of the output, just run it
and look at the exit code.

--

-- 
Stabbing you in the face so you don't have to.
Permalink | Reply | 0 comments |
headers
Zefram | 6 Sep 2007 10:27

optional dependencies

I've run into a problem building a CPAN distribution using Module::Build,
in an interesting way that raises questions about optional dependencies.
Specifically, I'm installing Crypt-MySQL-0.04, which comes with
both a Build.PL that uses Module::Build and a Makefile.PL that uses
ExtUtils::MakeMaker.  Building the EU::MM way works perfectly, and is
obviously what the author does himself.  Building the M::B way works
except for an undeclared dependency.

Crypt-MySQL includes some C code in an XS source file.  When M::B comes
to compile this, it wants to use ExtUtils::CBuilder.  I've only just
started using M::B, and didn't have EU::CB installed.  The Build.PL
script therefore emitted a warning, "Module::Build is not configured
with C_support".  However, that warning is only human-readable,
not machine-readable.  I was doing this install via the CPAN module.
CPAN went on to (I presume) request a prereq_report, but this report
doesn't say anything about EU::CB either.  CPAN then attempted to
build Crypt-MySQL, and the build immediately failed because of the lack
of EU::CB.

So, we have a dependency problem: Crypt-MySQL's build process required a
certain feature of M::B (compiling XS); that feature depends on EU::CB;
but the dependency is not installed.  C-MS is unaware of the dependency,
as it's only using the M::B interface, and M::B appears to be fully
installed.  C-MS could declare the dependency itself, as build_requires
=> { ExtUtils::CBuilder => "0.15" }, and I've submitted a patch to the
author to do that.  But this seems a dubious way to do things.  Other than
in this possible dependency declaration, the C-MS distribution doesn't
know anything about EU::CB; that name is not mentioned anywhere in the
C-MS tarball.  It uses EU::CB only indirectly.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zefram | 7 Sep 2007 12:48

Re: optional dependencies

Adam Kennedy wrote:
>Modules don't declare dependencies on distributions, and never have.

True.  But it's distributions that have the optional_features.

>They declare dependencies on APIs, described as namespace/version pairs.

So to fit in with this system, we could arrange for each optional feature
of a distribution to be reified as a module.  Consider the case I ran
into, where I want to declare a dependency on the C language support
aspects of Module::Build.  We can name this "Module::Build::C_support",
or something similar.  There'd be a Module-Build-C_support distribution,
with a META.yml containing

    name: Module-Build-C_support
    version: 0.01
    requires:
      Module::Build: 0
      ExtUtils::CBuilder: 0.15
    provides:
      Module::Build::C_support:
	file: C_support.pm
	version: 0.01

C_support.pm could almost be an empty file.  It would only ever be
"use"d or "require"d in order to check its existence and version number.
It would contain roughly

    package Module::Build::C_support;
    our $VERSION = "0.01";
(Continue reading)

Permalink | Reply | 3 comments |
headers
Craig A. Berry | 7 Sep 2007 17:17
Picon

[PATCH] some M::B::Platform::VMS fixes

I've checked the attached into blead as #31815.  It gets rid of a
call to eliminate_macros, which I don't think is needed in
Module::Build since there is no external make utility involved, and
it overrides expand_test_dir to make up for the fact that the
home-grown glob() returns absolute, not relative, paths.

--

-- 
________________________________________
Craig A. Berry
mailto:craigberry <at> mac.com

"... getting out of a sonnet is much more
  difficult than getting in."
                  Brad Leithauser
Attachment (mb_platform_vms.patch): application/octet-stream, 1469 bytes
Permalink | Reply | 0 comments |
headers
John Peacock | 7 Sep 2007 19:29
Picon

Re: optional dependencies

Zefram wrote:
> So to fit in with this system, we could arrange for each optional feature
> of a distribution to be reified as a module.  Consider the case I ran
> into, where I want to declare a dependency on the C language support
> aspects of Module::Build.

I don't think you have worked through this fully.  Assume for a second 
that Module::Build is installed first /sans/ ExtUtils::CBuilder, and 
hence this mystical C_support.pm is installed.  Now, you go ahead and 
install ExtUtils::CBuilder second, which has *no* connection to 
Module::Build::C_support.  How would that file get updated?  Would 
C_support merely attempt to load ExtUtils::CBuilder (via eval) and 
return the appropriate value depending?  That seems much more 
complicated for the framework author to code.

You may want to look at what I did in the version.pm distro.  It is 
actually pretty easy (once you see how) to check for optional features 
during your build and branch accordingly from your own Build.PL (or for 
that matter Makefile.PL).  I do similar magic in SVN::Notify::Mirror, 
where I can test various features depending on whether or not some 
optional modules are installed (though this case doesn't involve build 
dependencies).

I think it is really the individual module author's responsibility to 
code for their implicit dependencies, not the responsibility of the 
installation framework.  It is certainly possible that Module::Build 
could make it even easier to expose whether feature 'A' is installed 
_now_ (i.e. during the current build).  But I'm not sure that equating 
an optional feature with a phantom module is the way to go.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane