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

Re: [Module::Build] Yet Another Documentation Split

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

On Apr 14, 2006, at 5:23 AM, Randy W. Sims wrote:

> Ken Williams wrote:
>> On Mar 29, 2006, at 7:48 PM, Randy W. Sims wrote:
>>> I was looking over the Cookbook to see about clarifying the docs  
>>> on  adding new types of build elements, but to me it looks fine  
>>> for  what it is: basic quick recipes to accomplish a task. I  
>>> think the  two examples there cover the basic ideas. Perhaps we  
>>> could go into  more detail, but the Cookbook doesn't seem the  
>>> place for that.
>>>
>>> So I looked at putting a section in Authoring. Authoring is  
>>> filled  with pages and pages of reference on methods and  
>>> constructor args.  Then way down at the bottom is some background  
>>> info on creating  Build.PL scripts.
>>>
>>> I was thinking it be nice to just move the reference material to  
>>> a  another document, Reference.pod; and allow Authoring to be an   
>>> instructional guide to authoring.
>>>
>>> Should I do this? And is it ok to do so now? or wait?
>> How about calling the new document API.pod or something like that?
>> I'm not sure whether we should do that now or not - I think it   
>> wouldn't really cause much trouble, but I'd rather focus our  
>> efforts  more narrowly just now.  I could go either way, though.
>
> In the interests of focusing and enhancing the Authoring document  
> (and at the risk of being insubordinate) I've put together a  
> preliminary patch. I'd really like to get more information in there  
> about custom install elements, install paths, custom actions, etc;  
> and I think this will help make the information more accessible.  
> (and it took very little time to do it)

Cool, I've applied this patch.  Thanks.

As far as putting efforts into beefing up the various docs, that  
sounds to me like a 0.2801 thing.

  -Ken

Re: [Module::Build] How to use version.pm with M::B 0.26 (and 0.28)?

[David W. <da...@ki...>]

On Apr 14, 2006, at 12:51, Julian Mehnle wrote:

> If so, I'm even willing to employ hacks... uh... work-arounds.  But  
> I'm
> unsure how to get it working at all.  Any ideas?

Everything will work properly in 1.28, except that your module  
distribution will be named "My-Module-1.002003" instead of "My-Module- 
v1.2.3". This issue will be fixed after 0.28.

Best,

David

[Module::Build] How to use version.pm with M::B 0.26 (and 0.28)?

[Julian M. <ju...@me...>]

Hi all,

I know there have been several discussions about Module::Build's compati-=20
bility (or the lack thereof) with version.pm-using modules.  I understand=20
that proper version.pm support is planned for post-0.28.

However until 0.30 (or whatever post-0.28 means) will be released, I would=
=20
still like to use version.pm in my modules, in way as compatible as=20
possible.  The objectives are to have "1.2.3" (for instance) be displayed=20
as a module's version number on CPAN, and to have version comparisons=20
working correctly with Module::Build and in running code ("use=20
MyModule '1.2.3'").  Are those objectives, with M::B 0.26/0.28, compatible=
=20
with each other in the first place?

If so, I'm even willing to employ hacks... uh... work-arounds.  But I'm=20
unsure how to get it working at all.  Any ideas?

Julian.

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[demerphq <dem...@gm...>]

On 4/10/06, Randy W. Sims <ml...@th...> wrote:
> demerphq wrote:
> > On 4/10/06, Randy W. Sims <ml...@th...> wrote:
> >>I don't know how to resolve this issue. Since Archive::Tar is now in
> >>perl core, it may be worth bringing up there? Other tar programs, like
> >>GNU tar, create archives that work correctly in any archive tool.
> >
> >
> > Once i understand the problem I definately will bring it up with the
> > maintainers. Im pretty sure this wasnt a problem in older versions.
>
> <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/282/>
> <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/677/>

Ok, ive created a new bug report and patches to fix this. You can see them =
at:

   http://rt.cpan.org//Ticket/Display.html?id=3D18720

I actually asked RT to cc the list, but as I didnt see anything come
through I figured Id send out a heads up.

Cheers,
Yves


--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] ask() and you will receive

[David W. <da...@ki...>]

On Apr 14, 2006, at 02:44, Randy W. Sims wrote:

> +=item ask()
> +
> +[version 0.28]
> +
> +Asks the user a question and returns the answer as a string.
> +
> +The following is a list of arguments.  Only C<prompt> and C<default>
> +are required.
> +
> +=over
> +
> +=item allow_nonoption_default
>

I'd make this last. I tend to list options in the order of  
importance. So for this method, I would list them in this order:

=prompt
=default
=show_default
=options
=getopts_name
=show_options
=allow_nonoption_default

> +Normally, the value of the C<default> arguement must exist in the
> +C<options> array.

But only if there *is* an options array.

> Setting this to true allows the C<default> argument
> +to be set to an arbitrary value.
> +
> +=item default   [required]
> +
> +This is the default value that will be used if the user presses
> +E<lt>enterE<gt> or if running an unattended build.
> +
> +The value assigned to C<default> may be different from the options
> +listed in the C<options> argument.

But only if there *is* an options parameter and you've set  
allow_noniption_dfault to true.

> +=item show_default
> +
> +A boolean value that indicates whether the default value should be
> +displayed as part of the prompt.  If true and if the default is a
> +non-empty string,

And non-undef?

>  =item autosplit_file($from, $to)
>
>  [version 0.28]
> @@ -1437,6 +1514,8 @@
>
>  [version 0.12]
>
> +[Deprecated] See the C<ask()> method.
> +

What's deprecated, here?

Best,

David

Re: [Module::Build] ask() and you will receive

[David W. <da...@ki...>]

On Apr 14, 2006, at 01:07, Randy W. Sims wrote:

> Does the callback get called on every value the user enters? =20
> Regardless of whether it is an open ended query or a multiple =20
> choice selection?

Yes. Gotta make sure that whatever they type in is valid.

> Does it get called on values entered as command line options? or =20
> environment variables?

Let's see=85yes, it gets called on command-line options and environment =20=

variables. Anywhere that the user is putting in the option, you gotta =20=

check it. Only defaults are ignored.

> Using Text::Abbrev to accept short unique abbreviations for =20
> answers, do we validate before or after expansion?

I would do it after, but if there's an error, include the abbreviated =20=

version in the error message.

Best,

David=

[Module::Build] Re: How do I make a Build.PL to install a web app?

[Julian M. <ju...@me...>]

Randy W. Sims wrote:
> Stephen Adkins wrote:
> > I want to have a Build.PL which installs more than just scripts and
> > modules. I have a web application, and I want to install "cgi-bin"
> > programs, lots of files under "htdocs" (html, css, js, jpg, png, gif),
> > and various files under "share".
> > [...]
>
> I understand and agree with the need, but I'm not sure this is the best
> approach.
>
> We have one approach already that consists of feeding arguments to the
> constructor to indicate extra files to copy. This can be extended by
> subclassing and adding appropriate methods (eg find_${type}_files and
> process_${type}_files).

For the record, I was one of those who have asked this question here
before.  This is what I have come up with and been using so far (abridged
example taken from a CGI app of mine):

use Module::Build 0.26;

my $class = Module::Build->subclass( code => <<'EOF' );

    sub process_extra_files {
        my ($self, $dir) = @_;
        $dir ||= $element;
        File::Find::find(
            {
                wanted      => sub {
                    $File::Find::prune = 1 if -d and /\.svn$/;
                      # Exclude .svn dirs.
                    return if not -f;
                      # Handle files only.

                    my $destination = $self->copy_if_modified(
                        from    => $File::Find::name,
                        to      => File::Spec->catfile(
                                       $self->blib, $File::Find::name)
                    );
                    return if not defined($destination);
                      # Already up to date?

                    chmod((stat($File::Find::name))[2], $destination)
                        or warn("Couldn't set permissions on $destination: $!");
                },
                no_chdir    => 1
            },
            $dir
        );
    }

    sub process_etc_files     { shift->process_extra_files('etc')     }
    sub process_cgi_bin_files { shift->process_extra_files('cgi-bin') }
    sub process_sbin_files    { shift->process_extra_files('sbin')    }
    sub process_www_files     { shift->process_extra_files('www')     }

EOF

my $build = $class->new(
    module_name     => 'Thingy',
    # ...
    dist_version_from
                    => 'cgi-bin/thingy',
    # ...
    install_path    => {
        'etc'           => '/etc/thingy',
        'cgi-bin'       => '/usr/lib/cgi-bin',
        'sbin'          => '/usr/sbin',
        'lib'           => '/usr/share/thingy/lib',
        'www'           => '/usr/share/thingy/www',
    },
    # ...
    create_makefile_pl
                    => 'passthrough',
);

$build->add_build_element($_)
    foreach qw(etc cgi_bin sbin www);

$build->create_build_script();

__END__


I would like to see a more elegant solution to the custom-installation-
dirs problem in 0.28, too.

Re: [Module::Build] Invoking Build.PL/Makefile.PL from automake?

[Randy W. S. <ml...@th...>]

Tyler MacDonald wrote:
> 	I'm working on moving a project over to automake/libtool right now.
> There's perl modules in some subdirectories with their own Makefile.PL's.
> 
> 	Is there already some m4 macros around that will let me build perl
> modules from automake? Or any other projects doing the same thing I could
> learn from? I could write my own macros or add raw makefile snippets but if
> a well rounded solution already out there, I'd rather use that.

I don't know enough about the autotools to answer, but I'd be very 
curious to learn what you come up with.

Randy.

Re: [Module::Build] Yet Another Documentation Split

[Randy W. S. <ml...@th...>]

Ken Williams wrote:
> 
> On Mar 29, 2006, at 7:48 PM, Randy W. Sims wrote:
> 
>> I was looking over the Cookbook to see about clarifying the docs on  
>> adding new types of build elements, but to me it looks fine for  what 
>> it is: basic quick recipes to accomplish a task. I think the  two 
>> examples there cover the basic ideas. Perhaps we could go into  more 
>> detail, but the Cookbook doesn't seem the place for that.
>>
>> So I looked at putting a section in Authoring. Authoring is filled  
>> with pages and pages of reference on methods and constructor args.  
>> Then way down at the bottom is some background info on creating  
>> Build.PL scripts.
>>
>> I was thinking it be nice to just move the reference material to a  
>> another document, Reference.pod; and allow Authoring to be an  
>> instructional guide to authoring.
>>
>> Should I do this? And is it ok to do so now? or wait?
> 
> 
> How about calling the new document API.pod or something like that?
> 
> I'm not sure whether we should do that now or not - I think it  wouldn't 
> really cause much trouble, but I'd rather focus our efforts  more 
> narrowly just now.  I could go either way, though.

In the interests of focusing and enhancing the Authoring document (and 
at the risk of being insubordinate) I've put together a preliminary 
patch. I'd really like to get more information in there about custom 
install elements, install paths, custom actions, etc; and I think this 
will help make the information more accessible. (and it took very little 
time to do it)

Randy.

Re: [Module::Build] How do I make a Build.PL to install a web app?

[Randy W. S. <ml...@th...>]

Stephen Adkins wrote:
> Hi,
> 
> I want to have a Build.PL which installs more than just scripts and modules.
> I have a web application, and I want to install "cgi-bin" programs,
> lots of files
> under "htdocs" (html, css, js, jpg, png, gif), and various files under "share".
> 
> How can I do this? (See examples below.)
> Is the "install_extra_dirs" option a good enhancement? (see below)
> 
> I have a way to do this (barely) with MakeMaker, and if I can't figure out how
> to do this with Module::Build, I will have to go back to Makefile.PL in some
> of my distributions.

I understand and agree with the need, but I'm not sure this is the best 
approach.

We have one approach already that consists of feeding arguments to the 
constructor to indicate extra files to copy. This can be extended by 
subclassing and adding appropriate methods (eg find_${type}_files and 
process_${type}_files).

If we're going to extend/enhance this functionality, I think we need to 
take a different approach than feeding yet more arguments to the 
constructor since it doesn't really accomplish any more than we can do 
now. In particular it's not flexible enough to specify file to file and 
directory to directory copies, nor does it allow custom attributes/file 
modes to be assigned.

As we've talked about before, I'd like to add a method to allow easy, 
one call, way to set up custom install elements. But I'm holding off in 
the interest of getting 0.28 out.

This is a very high priority item with all of the questions we get about 
it, but we really need to get 0.28 out. I'll try to get the docs updated 
a bit to help authors understand the current methods better for the 0.28 
release.

Regards,
Randy.

Re: [Module::Build] ask() and you will receive

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Apr 11, 2006, at 15:32, Randy W. Sims wrote:
> 
>> I'm going to try my best to get this one wrapped up and committed  
>> tonight, possibly including some of the mentioned extensions.
> 
> 
> Cool.

I missed my deadline.

Attached is my working patch, tests included.

I didn't implement the config file or environment variable checking. I 
don't really see them as being generally applicable. They're more 
specialized, and the behavior can be supplied easily enough by the 
author before calling ask().

The only thing I plan to add is the on_validate callback mentioned 
earlier. I'm still debating the best time/circumstances to invoke the 
callback.

Randy.

Re: [Module::Build] ask() and you will receive

[Randy W. S. <ml...@th...>]

David Wheeler wrote:

> =item callback
> 
> A code reference that validates a value input by a user. The value to  
> be checked will be passed in as the first argument and will also be  
> stored in C<$_>. For example, if you wanted to ensure that a value  was 
> an integer, you might pass a code reference like C<sub { /^\d+$/ } >. 
> Note that if the callback sets C<$_> to a different value, the  revised 
> value is the one that will be returned. This can be useful  for parsing 
> one value from another.

Does the callback get called on every value the user enters? Regardless 
of whether it is an open ended query or a multiple choice selection?

Does it get called on values entered as command line options? or 
environment variables?

Using Text::Abbrev to accept short unique abbreviations for answers, do 
we validate before or after expansion?

Randy.

Re: [Module::Build] META.yml and platform dependencies.

[demerphq <dem...@gm...>]

On 4/13/06, Ken Williams <ke...@ma...> wrote:
>
> On Apr 13, 2006, at 1:40 AM, demerphq wrote:
>
> > Seems like if the META.yml creation occured on the installers machine
> > instead of on the distributors machine the problem would go away, and
> > allow inifinte flexibility.
> >
> > So for the time being it looks like I have to hand hack my MakeMaker
> > or something. Hmm.
>
> That won't work.  CPAN is looking at the META.yml file before running
> *anything*, including your MakeMaker code.

Actually I meant my ExtUtils-MakeMaker installation. Ill have to hand
hack it to prevent the  reference to Win32API::File being included in
the dist.

> Also, there's already a file called _blib/prereqs that's written
> while running the Build.PL script, and will contain any dynamically
> specified prereqs.
>
> I did bring up this issue with Andreas when he was proposing the
> META.yml-reading behavior for CPAN, but he figured he's cross that
> bridge when we came to it.  I think we've come to it?

Yep, seems like.

Cheers,
Yves


--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

[Module::Build] How do I make a Build.PL to install a web app?

[Stephen A. <spa...@gm...>]

Hi,

I want to have a Build.PL which installs more than just scripts and modules=
.
I have a web application, and I want to install "cgi-bin" programs,
lots of files
under "htdocs" (html, css, js, jpg, png, gif), and various files under "sha=
re".

How can I do this? (See examples below.)
Is the "install_extra_dirs" option a good enhancement? (see below)

I have a way to do this (barely) with MakeMaker, and if I can't figure out =
how
to do this with Module::Build, I will have to go back to Makefile.PL in som=
e
of my distributions.

Stephen

#########################################################
# Build.PL (with desired features)
#########################################################

use Module::Build;

my $build =3D Module::Build->new (
    dist_name         =3D> "Foo-WebApp",
    dist_version_from =3D> "lib/Foo/WebApp.pm",
    dist_author       =3D> "sadkins\@therubicongroup.com",
    dist_abstract     =3D> "A hot Web App",
    license           =3D> "perl",
    # this is the desired new option.
    # it would install the directories and all files from the distribution
    # directory to the "install_base" directory.
    # i.e. "./htdocs" gets copied to "/usr/local/htdocs".
    # meanwhile, shebang substitution also takes place.
    install_extra_dirs =3D> [ "bin", "cgi-bin", "htdocs", "share" ],
);

$build->create_build_script;

#########################################################
# Makefile.PL (which basically does the job)
#########################################################

######################################################################
## File: $Id: Makefile.PL,v 1.2 2005/04/13 17:53:58 spadkins Exp $
######################################################################

use ExtUtils::MakeMaker;

my @programs =3D <bin/[a-z]*>;

WriteMakefile(
    'NAME'         =3D> 'Foo-WebApp',
    'DISTNAME'     =3D> 'Foo-WebApp',
    'VERSION_FROM' =3D> 'lib/Foo/WebApp.pm',
    'EXE_FILES'    =3D> [ @programs ],
);

# Note: The PREFIX variable must be set at "make" time.
sub MY::postamble {
    return <<EOF;

install ::
    @\$(MOD_INSTALL) htdocs    \$(PREFIX)/htdocs
    @\$(MOD_INSTALL) cgi-bin   \$(PREFIX)/cgi-bin
    @\$(MOD_INSTALL) share     \$(PREFIX)/share
    \$(PERL) -e "mkdir('\$(PREFIX)/log') if (! -d '\$(PREFIX)/log');"

EOF
}

Re: [Module::Build] META.yml and platform dependencies.

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

On Apr 13, 2006, at 10:25 AM, Chris Dolan wrote:

> On Apr 13, 2006, at 1:40 AM, demerphq wrote:
>
>> Seems like if the META.yml creation occured on the installers machine
>> instead of on the distributors machine the problem would go away, and
>> allow inifinte flexibility.
>
> Heh, that scenario would remove the need for a META.yml completely,  
> wouldn't it?
>
> Unfortunately, that doesn't solve the reason for META.yml's  
> existence: to allow people to inspect module metadata without  
> needing to execute untrusted code.

The reason for having the META.yml isn't really security, but more  
convenience.  Version numbers, author names, module names, abstracts,  
etc. are spread out all over the tarball usually, but the META.yml  
just puts them in one place.

It can be a security issue for the PAUSE site or search.cpan.org or  
whatever, which might receive a poison tarball, but for the average  
user they've opened themselves wide open anyway.

  -Ken

Re: [Module::Build] META.yml and platform dependencies.

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

On Apr 13, 2006, at 1:40 AM, demerphq wrote:

> Seems like if the META.yml creation occured on the installers machine
> instead of on the distributors machine the problem would go away, and
> allow inifinte flexibility.
>
> So for the time being it looks like I have to hand hack my MakeMaker
> or something. Hmm.

That won't work.  CPAN is looking at the META.yml file before running  
*anything*, including your MakeMaker code.

Also, there's already a file called _blib/prereqs that's written  
while running the Build.PL script, and will contain any dynamically  
specified prereqs.

I did bring up this issue with Andreas when he was proposing the  
META.yml-reading behavior for CPAN, but he figured he's cross that  
bridge when we came to it.  I think we've come to it?

  -Ken

Re: [Module::Build] META.yml and platform dependencies.

[demerphq <dem...@gm...>]

On 4/13/06, Chris Dolan <ch...@cl...> wrote:
> On Apr 13, 2006, at 1:40 AM, demerphq wrote:
>
> > Seems like if the META.yml creation occured on the installers machine
> > instead of on the distributors machine the problem would go away, and
> > allow inifinte flexibility.
>
> Heh, that scenario would remove the need for a META.yml completely,
> wouldn't it?

Depends what you consider the objective of having a META.yml

If its to provide a clean abstraction layer for installation agents
like CPAN to process then no.

> Unfortunately, that doesn't solve the reason for META.yml's
> existence: to allow people to inspect module metadata without needing
> to execute untrusted code.

If the objective is to avoid the execution of untrusted code then no
you would be right.

But im not sure that that is the objective. Im not saying it isnt,
but, it seems to me that a client like CPAN is going to execute the
Makefile.PL or Build.PL regardless, so it doesnt seem to me like its a
big win in terms of security.

I mean, it seems to me the difference is purely one of whether the
client executes the build script _before_ or _after_ reading the
META.yml.  Given that i see no change in the security profile.

Yves

--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] META.yml and platform dependencies.

[Chris D. <ch...@cl...>]

On Apr 13, 2006, at 1:40 AM, demerphq wrote:

> Seems like if the META.yml creation occured on the installers machine
> instead of on the distributors machine the problem would go away, and
> allow inifinte flexibility.

Heh, that scenario would remove the need for a META.yml completely,  
wouldn't it?

Unfortunately, that doesn't solve the reason for META.yml's  
existence: to allow people to inspect module metadata without needing  
to execute untrusted code.

Chris
-- 
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: [Module::Build] META.yml and platform dependencies.

[demerphq <dem...@gm...>]

On 4/13/06, Ken Williams <ke...@ma...> wrote:
> Hi Yves,
>
> This is a known shortcoming of CPAN's approach to dependency
> detection.  There's no solution inside the META.yml itself, though in
> some distant future version we'd like to expand the little language
> that describes dependencies so it would indeed be capable of
> expressing platform-specific dependencies.
>
> In the meantime, I'm not sure what to suggest - if you omit the
> META.yml I assume CPAN would try another method, but I'm not sure.
> It's also possible that if you put dynamic_config =3D> 1 in the
> META.yml it could try another method, but I'm certainly not sure
> about that either. :-/

Seems like if the META.yml creation occured on the installers machine
instead of on the distributors machine the problem would go away, and
allow inifinte flexibility.

So for the time being it looks like I have to hand hack my MakeMaker
or something. Hmm.

Yves


--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] META.yml and platform dependencies.

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

Hi Yves,

This is a known shortcoming of CPAN's approach to dependency  
detection.  There's no solution inside the META.yml itself, though in  
some distant future version we'd like to expand the little language  
that describes dependencies so it would indeed be capable of  
expressing platform-specific dependencies.

In the meantime, I'm not sure what to suggest - if you omit the  
META.yml I assume CPAN would try another method, but I'm not sure.   
It's also possible that if you put dynamic_config => 1 in the  
META.yml it could try another method, but I'm certainly not sure  
about that either. :-/

  -Ken


On Apr 12, 2006, at 12:36 PM, demerphq wrote:

> I have a problem with META.yml generation and platform dependencies.
>
> It looks to me like CPAN is using META.yml to resolve dependencies
> instead of letting Build.PL or Makefile.PL handle it. But there doesnt
> appear to be a way to express that in a  METAL.yml. So when i do a
> build/make dist I end up with a METAL.yml that specifies a win32
> specific dependency, and when people on other OSes try to build they
> try to grab a win32 specifc module.
>
> Before I hack whatever it is that generates the META.yml to handle
> this im wondering if there is anything better to be done? What happens
> if a package doesnt contain a META.yml?
>
> I also think it raises an interesting question. How to express dynamic
> dependencies in a form like META.yml? It seems to me only in a limited
> fashion.

[Module::Build] Invoking Build.PL/Makefile.PL from automake?

[Tyler M. <ty...@yi...>]

	I'm working on moving a project over to automake/libtool right now.
There's perl modules in some subdirectories with their own Makefile.PL's.

	Is there already some m4 macros around that will let me build perl
modules from automake? Or any other projects doing the same thing I could
learn from? I could write my own macros or add raw makefile snippets but if
a well rounded solution already out there, I'd rather use that.

	Thanks!

		- Tyler

[Module::Build] META.yml and platform dependencies.

[demerphq <dem...@gm...>]

I have a problem with META.yml generation and platform dependencies.

It looks to me like CPAN is using META.yml to resolve dependencies
instead of letting Build.PL or Makefile.PL handle it. But there doesnt
appear to be a way to express that in a  METAL.yml. So when i do a
build/make dist I end up with a METAL.yml that specifies a win32
specific dependency, and when people on other OSes try to build they
try to grab a win32 specifc module.

Before I hack whatever it is that generates the META.yml to handle
this im wondering if there is anything better to be done? What happens
if a package doesnt contain a META.yml?

I also think it raises an interesting question. How to express dynamic
dependencies in a form like META.yml? It seems to me only in a limited
fashion.

cheers,
Yves

--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5891 - in Module-Build/trunk: . lib/Module/Build

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

On Apr 12, 2006, at 2:26 AM, demerphq wrote:

> On 4/12/06, Ken Williams <ke...@ma...> wrote:
>>
>> On Apr 11, 2006, at 6:46 PM, Randy W. Sims wrote:
>>
>>> Ken Williams wrote:
>>>> Hey,
>>>> I wonder whether we should check for executability with "-x $file"
>>>> rather than "(stat $file)[2] & 0111".  Besides being simpler, it
>>>> seems like it might DTRT on more platforms, where stat values
>>>> might be nontrustworthy.
>>>
>>> You mean like so:
>>>
>>>  $mode = 0444 | ( -x $file ? 0111 : 0 );
>>
>> Yup, I'll make the change.
>
> Seems to me that if -x and stat with the appropriate mask arent
> returning the same thing you have a bug in Perl.

Not necessarily.  On Unix, for example, if the permissions on a file  
you own are 0445, then "(stat $file)[2] & 0111" will return true but  
"-x $file" will return false.  Maybe that means we're not using "the  
appropriate mask", but what would an appropriate mask be in all the  
situations we care about?  Probably none exists.

  -Ken

Re: [Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5891 - in Module-Build/trunk: . lib/Module/Build

[demerphq <dem...@gm...>]

On 4/12/06, Ken Williams <ke...@ma...> wrote:
>
> On Apr 11, 2006, at 6:46 PM, Randy W. Sims wrote:
>
> > Ken Williams wrote:
> >> Hey,
> >> I wonder whether we should check for executability with "-x $file"
> >> rather than "(stat $file)[2] & 0111".  Besides being simpler, it
> >> seems like it might DTRT on more platforms, where stat values
> >> might be nontrustworthy.
> >
> > You mean like so:
> >
> >  $mode =3D 0444 | ( -x $file ? 0111 : 0 );
>
> Yup, I'll make the change.

Seems to me that if -x and stat with the appropriate mask arent
returning the same thing you have a bug in Perl. The only situation in
blead where Im not sure that they will be identical is VMS, otherwise
from what i can tell the -X tests are just perl doing the appropriate
masking for you. Where stat doesnt behave correctly Perl fakes it. Or
at least from what I can tell it /should/.

Do you guys actually have evidence that they are different somewhere?
Have I missed something in the docs?

Cheers,
Yves

--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] [Fwd: Smoke [5.9.4] 27752 FAIL(X) AIX 4.3.3.0/ML11 (PPC/1 cpu)]

[Ron S. <ro...@sa...>]

On Tue, 11 Apr 2006 23:22:07 -0400, Randy W. Sims wrote:

Hi Randy

> The failure below has nothing to do with Module::Build, but we are
> leaving some files behind on AIX. I think, looking at
> ExtUtils::MkSymlists, that aix is the only place where these are
> created.

There must be something else going on, too, since (with 0.2611) I occasionally
get a dir left called d:\My-Module-\d{4}. I work in d:, so the drive is correct.

I have not been able yet to determine what circumstances lead to this file being
left.

--
Ron Savage
ro...@sa...
http://savage.net.au/index.html