gmane.comp.lang.perl.modules.module-build

Question about documentation targets

Chris Maloney — 2012-04-28T13:46:15

Good day, all!

This is a newbie question.  I am trying to set up a build/development
environment for my CPAN module under Windows.  I'm switching between
cygwin and Strawberry Perl, and haven't settled on one or the other
yet -- and in fact maybe I'll continue to use both, so as to provide a
little more testing.

Under strawberry, the problem that I'm having now, is that when I type
"build" in my module's development directory, it is not building any
of my module's documentation:  I get no bindoc, libdoc, binhtml, or
libhtml in blib.

According to the documentation, the 'build' action is supposed to
build 'docs'.  This is consistent, in that at least, when I type
'build docs', I also get no documentation directories.  However, when
I type 'build html', I do get the two html directories, and when I
type 'build manpages', I get the two doc directories.

I would have thought that 'build docs' would do the same as 'build
html' and 'build manpages'.  Why doesn't it?

The documentation also says that, for

Re: Ending Build.PL if there are missing modules

Adam Kennedy — 2012-02-05T02:43:32

If the goal is only to pick up versioned dependencies, I'm surprised
we even need to bother with that.

For M:I I've been thinking of just scanning all of script and lib for
/^use Module::Name 1.23/ to determine requires, and all of t to find
build_requires/test_requires.

Anything loaded without a specific numeric version would be ignored
and would have to be specified with a manual requires statement.

I'd filter out POD and comment lines, but I wouldn't bother with full
source parsing (can't really do that inside M:I anyway since I'd have
to bundle PPI).

Adam

On Sun, Feb 5, 2012 at 12:23 PM, David Golden <xdaveg< at >gmail.com> wrote:

Re: Ending Build.PL if there are missing modules

Adam Kennedy — 2012-02-04T22:17:53

That's how Module::Install's requires_from does it too.

I should look at zilla's code and see how it runs, might be worth
aligning M:I and it's detection.

Adam

On Sun, Feb 5, 2012 at 12:31 AM, David Golden <xdaveg< at >gmail.com> wrote:

Re: Ending Build.PL if there are missing modules

Adam Kennedy — 2012-02-05T02:51:55

I was thinking about dropping anything without a specific numberic
version completely and requiring manual, because I figure the chances
for misidentification is too high (whereas a number will only really
be there after a human has put some specific thought into it).

Adam

On Sun, Feb 5, 2012 at 1:50 PM, David Golden <xdaveg< at >gmail.com> wrote:

Re: Ending Build.PL if there are missing modules

David Golden — 2012-02-05T11:38:36

That's a different use case (though a neat trick).  Seeing optional
dependency load attempts is different than knowing which ones should
be included in metadata (and whether they should be "recommends" or
"suggests" or omitted) and what version of them are required.

Re: Ending Build.PL if there are missing modules

Eric Wilhelm — 2012-02-05T06:15:58

# from David Golden
# on Saturday 04 February 2012 17:23:


I've experimented with detecting those using my Devel::TraceDeps on the 
running test suite.  It is possible to see the source and target of 
every require(), including failed ones (so you have to be using 
eval+require, but you already knew it was incorrect to go stat()ing 
around in < at >INC looking for your optional deps.)

--Eric

Re: Ending Build.PL if there are missing modules

David Golden — 2012-02-05T03:05:00

You're sort of talking about the equivalent of "use strict" for module
importing.  (Though note that it can't be done via C<use parent
'Foo'>.)

I think that's a sensible strategy, though I think you'll annoy people
who really want it to DWIM rather than have to be explicit about it.

Re: Ending Build.PL if there are missing modules

David Golden — 2012-02-05T02:50:03

It picks up as many "standard" dependencies as it can, but treats
anything without a version as requesting version 0.

Re: Ending Build.PL if there are missing modules

David Golden — 2012-02-05T01:23:05

It uses Ricardo's Perl::PrereqScanner, which does a pretty sane job of
it (even detects base/parent and so on).  It has some extensions for
picking up Moose and POE prereqs and so on.

It doesn't help with optional, dynamic prereqs so those have to be
specified manually, but that's unavoidable I think.

David

Re: Ending Build.PL if there are missing modules

David Golden — 2012-02-04T13:31:28

Plenty of code has dependencies listed that aren't truly required and
tests will pass with lower versions.

The proper way to enforce dependencies is in a "use" statement:

  use Foo::Bar 1.23;

Not coincidentally, that's how Dist::Zilla detects dependencies,
ensuring that code and specified prereqs are actually in sync.

In my view, other tools are doing it wrong.

Re: Ending Build.PL if there are missing modules

Leon Timmermans — 2012-02-04T12:48:24

On Sat, Feb 4, 2012 at 1:32 AM, Adam Kennedy
<adamkennedybackup< at >gmail.com> wrote:

I tend to agree with that. I've been writting Test::CheckDeps
(warning: very much a 0.001 release) to make it crap out as early as
possible during testing, but it could be even earlier.

Leon

Re: Ending Build.PL if there are missing modules

Leon Timmermans — 2012-02-04T11:56:37

2012/2/4 Alberto Simões <albie< at >alfarrabio.di.uminho.pt>:

There are two ways to do this. You can do this early enough during
build, the PL_files feature would be the most obvious way.
Alternatively you can add Parse::Yapp to configure requires (no need
to add a check for that, it will die by itself if it's missing), but
that will crap out on legacy perls without having any obvious
advantages.

Leon

Re: Ending Build.PL if there are missing modules

Alberto Simões — 2012-02-04T10:53:31

Hello

On 04/02/12 01:33, Michael G Schwern wrote:

Basically, I depend on Parse::Yapp, and I would like to call `yapp` on 
Build.PL so I can have the generated .pm file before M::B generates all 
its data dir.

In fact, I can add that to inc/MyBuilder.pm, but I am afraid the 
generated .pm will not be installed.

But probably I am just too used to MakeMaker and M::B will work just fine :)

Cheers
ambs

Re: Ending Build.PL if there are missing modules

Michael G Schwern — 2012-02-04T02:29:55

This should be enforced not by the build tool, which cannot resolve the
dependencies itself, but by the tool running the install.

And I mean both meanings of "tool". ;)

Re: Ending Build.PL if there are missing modules

Michael G Schwern — 2012-02-04T01:33:29

MakeMaker has something like what Alberto wants, PREREQ_FATAL.  It's
considered a misfeature for exactly the reasons above.  It doesn't let the
configuration step complete so tools cannot resolve the dependencies and
continue building.

Alberto, what are you trying to accomplish here?  There's probably a way to do it.

Re: Ending Build.PL if there are missing modules

Adam Kennedy — 2012-02-04T00:32:29

While I agree it needs to finish, I do kind of wish dependencies could
be enforced at the build module level so that tests couldn't run until
dependencies are satisfied.

Adam

On 4 February 2012 10:22, Leon Timmermans <fawaka< at >gmail.com> wrote:

Re: Ending Build.PL if there are missing modules

Leon Timmermans — 2012-02-03T23:22:13

2012/2/3 Alberto Simões <albie< at >alfarrabio.di.uminho.pt>:

Hi Alberto,

You shouldn't make it stop. «perl Build.PL» does configuration, not
building. Hence build or runtime requirements are not required to be
satisfied. What you're observing is not an error in any way, but an
essential step in the process. It gives the install tool the chance to
tell the cpan client (or the end user, if he's installing by hand) the
opportunity what dependencies to install.

If there are any missing dependencies, you'll notice it soon enough
(in particular when doing «./Build test».

Leon

Ending Build.PL if there are missing modules

Alberto Simões — 2012-02-03T21:50:46

Hello

Builder->new seems to check if all required modules are available. But 
if any fails, it continues to process the Build.PL file.

Is there any way to make it stop?

Thanks

Re: Stopping a Pointless C Compiler Warning

John M. Gamble — 2012-01-11T16:43:15

Thanks. Pity they don't seem to have a solution.

     -john

Re: Stopping a Pointless C Compiler Warning

Fields, Christopher J — 2012-01-11T03:16:54

That message originates from Activestate's ppm; see this link:

http://community.activestate.com/node/7553

chris

On Jan 10, 2012, at 8:36 PM, John M. Gamble wrote:


Chris Fields
Senior Research Scientist
National Center for Supercomputing Applications
Institute for Genomic Biology
University of Illinois at Urbana-Champaign

Stopping a Pointless C Compiler Warning

John M. Gamble — 2012-01-11T02:36:38

I don't know which upgrade brought this, but currently when I use Build.PL
(and the resulting Build files) I get (in reverse video no less) the
message:

It looks like you don't have a C compiler on your PATH, so you will not be
able to compile C or XS extension modules.  You can install GCC from the
MinGW package using the Perl Package Manager by running:

    ppm install MinGW

I've become somewhat numb to it, but it's a completely pointless and
unhelpful message, since this machine I'm working on will never develop
anything in C. I haven't been able to find anything in Module::Build
documentation that tells me how to tell it that this is a pure Perl
module. Can anyone steer me in the right direction?

I'm using ActiveState perl version 5.14.1, and Module::Build version 0.3800.

Thanks,
     -john