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

Re: [Module::Build] What to do? What to do?

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

On Fri, 07 Apr 2006 20:55:39 -0400, Randy W. Sims wrote:

Hi Randy

> Other ideas?

What you /really/ want is the definitive way of organizing ideas: TreePad:

http://www.treepad.com/

OK, so it's not web-based...
-- 
Cheers
Ron Savage, ro...@sa... on 8/04/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Module::Build] Document install_base_relpaths

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

On Apr 7, 2006, at 18:47, Randy W. Sims wrote:

> Yes, since prefix and install_base are different path layouts, it  
> makes sense to require them to be set separately so that the author  
> thinks about the different layouts.

Okay.

> Right. See in my previous example[1] how I checked for those  
> settings and issued a warning to the user when none were supplied.

Right, I see that, now. Maybe that example should be added to the  
cookbook, then? My module currently requires install_base, so I don't  
need to worry about prefix_relpaths.

Thanks, Randy, this is great!

Best,

David

Re: [Module::Build] Document install_base_relpaths

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

David Wheeler wrote:
> On Apr 7, 2006, at 15:52, Randy W. Sims wrote:
> 
>> If 'install_path' is set, elements will be installed to the set location.
> 
> Right, sure.
> 
>> If 'install_base' is set, and the author provides a relpath via 
>> install_base_relpath(), elements will be installed to 
>> install_base/relpath.
> 
> Perfect.
> 
>> If 'prefix' is set, and the author provides a relpath via 
>> prefix_relpath(), elements will be installed to prefix/relpath.
> 
> Oh, huh. So I need to specify both install_base_relpath *and* 
> prefix_relpath? Why wouldn't both be covered by a single method call?

Yes, since prefix and install_base are different path layouts, it makes 
sense to require them to be set separately so that the author thinks 
about the different layouts.

>> Otherwise it will not be installed.
> 
> So as a module author, if I require that it be installed, I just need to 
> make sure that both install_base_relpath and prefix_relpath are 
> specified and that the user use either install_path, install_base, or 
> prefix, right?

Right. See in my previous example[1] how I checked for those settings 
and issued a warning to the user when none were supplied.

Randy.

1. 
<http://article.gmane.org/gmane.comp.lang.perl.modules.module-build/3607/>

Re: [Module::Build] Document install_base_relpaths

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

On Apr 7, 2006, at 15:52, Randy W. Sims wrote:

> If 'install_path' is set, elements will be installed to the set  
> location.

Right, sure.

> If 'install_base' is set, and the author provides a relpath via  
> install_base_relpath(), elements will be installed to install_base/ 
> relpath.

Perfect.

> If 'prefix' is set, and the author provides a relpath via  
> prefix_relpath(), elements will be installed to prefix/relpath.

Oh, huh. So I need to specify both install_base_relpath *and*  
prefix_relpath? Why wouldn't both be covered by a single method call?

> Otherwise it will not be installed.

So as a module author, if I require that it be installed, I just need  
to make sure that both install_base_relpath and prefix_relpath are  
specified and that the user use either install_path, install_base, or  
prefix, right?

> The changes I made allow the above to work without further  
> tinkering with the internals by authors.

That's good. :-)

> None of my changes affect the code above in any way. Although, as  
> written, I think the code above is redundant. IIRC, the default  
> processing does exactly what your process_www_files() does as long  
> as you supply the find_www_files. But, again, that has nothing to  
> do with any changes I've recently made.

Oh, really? /me tries that...yep, sure enough. Thanks, Randy!

Best,

David

[Module::Build] What to do? What to do?

[Randy W. S. <Ra...@Th...>]

I don't know what to do.

I used to keep a list of todo items in my Treo. I have all kinds of 
stuff in there: some esoteric, some important. Sometimes I'll be working 
on something and think of something to check out later, so I'll jot down 
a note. Some stuff is just wishlist, fantasy stuff. But most of it is 
important stuff for this and the next couple releases.

The reason I haven't put it in RT or similar is that there is some stuff 
that just don't belong, some of it is just notes to myself, and it 
seemed to make sense to separate my todo from general user todo items.

But my Treo is falling apart after only an year and half of use (no more 
Treos, maybe RIM?), so I moved everything into an old fashioned 6"x9" 
notepad a couple months ago.

Now I've lost it.

It should be at home, in my car, or at the office, but I haven't found 
it yet after a week of looking. I can recover from the loss, though I'm 
still sure it'll turn up unless someone snatched it for their own use.

Anyway, what I was wondering is would it make sense to set up a tiny 
little wiki or something that could be used as a developer's notebook? 
It could be private or public, but I'll warn that some things I note 
down are best ignored. It would be nice to have it where others can 
review, notably Ken, so they can comment on items or leave answers to 
some of the questions I jot down that I haven't had a chance to look up.

The mailing-list is good for some of that, but it's hard to use as a 
reference. A wiki seems perfect for this type of thing.

If nothing else, I could try to set one up on my site, but I think 
Earthlink only has perl 5.004. I really need to find another host.

Other ideas?

BTW, this is not for right now. Sometime after 0.28.

Randy.

Re: [Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5869 - Module-Build/trunk/t

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

Stephen Adkins wrote:
> And which methods in particular make up "this family of methods" whose
> collective functionality are being reviewed?
> 
> (Or alternatively, which section(s) of the quite long Authoring document
> are under consideration?)

In the "METHODS" section, the methods

  install_path
  install_base_relpaths
  prefix_relpaths

Re: [Module::Build] Document install_base_relpaths

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

David Wheeler wrote:
> On Apr 6, 2006, at 10:53, Randy W. Sims wrote:
> 
>> Great. besides making the methods public and documenting them, the 
>> bigger change was one you don't see: During install it now knows to 
>> install the custom type whereas before it would not install them 
>> unless you specified an explicit --install-path or did some trickery 
>> under the hood. Eg. setting install_base_relpath and giving the 
>> --install-base option did nothing when installing.
> 
> So if I don't set install-path or install_base, where will it be 
> installed?

If 'install_path' is set, elements will be installed to the set location.

If 'install_base' is set, and the author provides a relpath via 
install_base_relpath(), elements will be installed to install_base/relpath.

If 'prefix' is set, and the author provides a relpath via 
prefix_relpath(), elements will be installed to prefix/relpath.

Otherwise it will not be installed.

The changes I made allow the above to work without further tinkering 
with the internals by authors.

> I thought that I needed to write process_[element]_files() to 
> set it up to do the right thing. For example, for my "www" element, I 
> have this method:
> 
> sub process_www_files {
>     my $self  = shift;
>     my $files = $self->find_www_files;
>     while (my ($file, $dest) = each %$files) {
>         $self->copy_if_modified(
>             from => $file,
>             to => File::Spec->catfile($self->blib, $dest)
>         );
>     }
> }
> 
> Do I no longer need that?

None of my changes affect the code above in any way. Although, as 
written, I think the code above is redundant. IIRC, the default 
processing does exactly what your process_www_files() does as long as 
you supply the find_www_files. But, again, that has nothing to do with 
any changes I've recently made.

Regards,
Randy.

Re: [Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5869 - Module-Build/trunk/t

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

And which methods in particular make up "this family of methods" whose
collective functionality are being reviewed?

(Or alternatively, which section(s) of the quite long Authoring document
are under consideration?)

Stephen

On 4/7/06, Randy W. Sims <ml...@th...> wrote:
> Stephen Adkins wrote:
> > Hi,
> >
> > I think this is a topic I am very interested in.
> >
> > 1. Can you direct us to the documentation that describes the capabiliti=
es
> >     that we are pausing to review?
> >     (And which methods make up "this family of methods"?)
> >
> > 2. If it is not documented, may I suggest that the first order of busin=
ess is
> >     to document it so that we may pause to review it together?
>
> <http://svn.perl.org/modules/Module-Build/trunk/lib/Module/Build/Authorin=
g.pod>
>
> Randy.
>

Re: [Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5869 - Module-Build/trunk/t

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

Stephen Adkins wrote:
> Hi,
> 
> I think this is a topic I am very interested in.
> 
> 1. Can you direct us to the documentation that describes the capabilities
>     that we are pausing to review?
>     (And which methods make up "this family of methods"?)
> 
> 2. If it is not documented, may I suggest that the first order of business is
>     to document it so that we may pause to review it together?

<http://svn.perl.org/modules/Module-Build/trunk/lib/Module/Build/Authoring.pod>

Randy.

Re: [Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5869 - Module-Build/trunk/t

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

Hi,

I think this is a topic I am very interested in.

1. Can you direct us to the documentation that describes the capabilities
    that we are pausing to review?
    (And which methods make up "this family of methods"?)

2. If it is not documented, may I suggest that the first order of business =
is
    to document it so that we may pause to review it together?

Thanks,
Stephen

On 4/7/06, Ken Williams <ke...@ma...> wrote:
> I'm not sure about this one - it seems weird to set the path with
> Unix-like syntax but get the result in local syntax.
>
> Can we take a little pause to review the APIs for this family of
> methods?  I think there's also some inconsistency between
> install_base_* and prefix_*, from back when I was a little confused
> about them.
>
>   -Ken
>
>
> On Apr 6, 2006, at 10:31 PM, ra...@cv... wrote:
>
> > Author: randys
> > Date: Thu Apr  6 20:31:02 2006
> > New Revision: 5869
> >
> > Modified:
> >    Module-Build/trunk/t/destinations.t
> >
> > Log:
> > Fixup some cross-platform paths.
> >
> > Modified: Module-Build/trunk/t/destinations.t
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > =3D=3D=3D=3D=3D=3D=3D=3D
> > --- Module-Build/trunk/t/destinations.t       (original)
> > +++ Module-Build/trunk/t/destinations.t       Thu Apr  6 20:31:02 2006
> > @@ -92,10 +92,10 @@
> >      like( $@, qr/Value must be a relative path/, '  emits error if
> > path not relative' );
> >
> >      $path =3D $mb->install_base_relpaths('elem' =3D> 'foo/bar');
> > -    is( $path, 'foo/bar', '  returns assigned path' );
> > +    is( $path, catdir(qw(foo bar)), '  returns assigned path' );
> >
> >      $path =3D $mb->install_base_relpaths('elem');
> > -    is( $path, 'foo/bar', '  can read stored path' );
> > +    is( $path, catdir(qw(foo/bar)), '  can read stored path' );
> >
> >      $map =3D $mb->install_base_relpaths();
> >      is_deeply( $map->{elem}, [qw(foo bar)], '  can access map' );
> > @@ -121,10 +121,10 @@
> >      like( $@, qr/Value must be a relative path/, '  emits error if
> > path not relative' );
> >
> >      $path =3D $mb->prefix_relpaths('site', 'elem' =3D> 'foo/bar');
> > -    is( $path, 'foo/bar', '  returns assigned path' );
> > +    is( $path, catdir(qw(foo bar)), '  returns assigned path' );
> >
> >      $path =3D $mb->prefix_relpaths('site', 'elem');
> > -    is( $path, 'foo/bar', '  can read stored path' );
> > +    is( $path, catdir(qw(foo bar)), '  can read stored path' );
> >
> >      $map =3D $mb->prefix_relpaths();
> >      is_deeply( $map->{elem}, [qw(foo bar)], '  can access map' );
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language
> > that extends applications into web and mobile media. Attend the
> > live webcast
> > and join the prime developer group breaking into this new coding
> > territory!
> > http://sel.as-us.falkag.net/sel?
> > cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=3D121642
> > _______________________________________________
> > Module-build-checkins mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/module-build-checkins
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
>

Re: [Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5869 - Module-Build/trunk/t

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

Ken Williams wrote:
> I'm not sure about this one - it seems weird to set the path with 
> Unix-like syntax but get the result in local syntax.
> 
> Can we take a little pause to review the APIs for this family of 
> methods?  I think there's also some inconsistency between install_base_* 
> and prefix_*, from back when I was a little confused about them.

Yeah, I guess it does seem weird. I wanted to avoid passing in an array 
of path names because it seemed a bit clunky. Since it will be used by 
authors and be expected to work on all platforms, it seemed natural to 
pass in a nutrual, single-style path syntax. I chose unix like paths 
since we do this elsewhere.

That leaves the return value. I figured the return value should be 
immediately usable without the author having to perform the conversion 
from unix to a localized path, so I performed the conversion before 
returning.

The logic made sense to me as I was doing it, but the end result, at 
first glance, does seem unusual.

Randy.

[Module::Build] Re: [Module-build-checkins] [svn:Module-Build] r5869 - Module-Build/trunk/t

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

I'm not sure about this one - it seems weird to set the path with  
Unix-like syntax but get the result in local syntax.

Can we take a little pause to review the APIs for this family of  
methods?  I think there's also some inconsistency between  
install_base_* and prefix_*, from back when I was a little confused  
about them.

  -Ken


On Apr 6, 2006, at 10:31 PM, ra...@cv... wrote:

> Author: randys
> Date: Thu Apr  6 20:31:02 2006
> New Revision: 5869
>
> Modified:
>    Module-Build/trunk/t/destinations.t
>
> Log:
> Fixup some cross-platform paths.
>
> Modified: Module-Build/trunk/t/destinations.t
> ====================================================================== 
> ========
> --- Module-Build/trunk/t/destinations.t	(original)
> +++ Module-Build/trunk/t/destinations.t	Thu Apr  6 20:31:02 2006
> @@ -92,10 +92,10 @@
>      like( $@, qr/Value must be a relative path/, '  emits error if  
> path not relative' );
>
>      $path = $mb->install_base_relpaths('elem' => 'foo/bar');
> -    is( $path, 'foo/bar', '  returns assigned path' );
> +    is( $path, catdir(qw(foo bar)), '  returns assigned path' );
>
>      $path = $mb->install_base_relpaths('elem');
> -    is( $path, 'foo/bar', '  can read stored path' );
> +    is( $path, catdir(qw(foo/bar)), '  can read stored path' );
>
>      $map = $mb->install_base_relpaths();
>      is_deeply( $map->{elem}, [qw(foo bar)], '  can access map' );
> @@ -121,10 +121,10 @@
>      like( $@, qr/Value must be a relative path/, '  emits error if  
> path not relative' );
>
>      $path = $mb->prefix_relpaths('site', 'elem' => 'foo/bar');
> -    is( $path, 'foo/bar', '  returns assigned path' );
> +    is( $path, catdir(qw(foo bar)), '  returns assigned path' );
>
>      $path = $mb->prefix_relpaths('site', 'elem');
> -    is( $path, 'foo/bar', '  can read stored path' );
> +    is( $path, catdir(qw(foo bar)), '  can read stored path' );
>
>      $map = $mb->prefix_relpaths();
>      is_deeply( $map->{elem}, [qw(foo bar)], '  can access map' );
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Module-build-checkins mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-checkins

Re: [Module::Build] Preserving files' executable bits, once more

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

Julian Mehnle wrote:
> Hi M::B developers,
> 
> in October 2004, I reported a bug that M::B wasn't preserving the 
> executable bits of files when creating a dist tarball (i.e. with the 
> "dist" action).[1]  The issue was resolved in M::B 0.27_01 by an addition 
> of chmodding code to the Module::Build::Base::ACTION_distdir() method.[2]
> 
> Now I'm experiencing a similar problem in a slightly different situation.  
> I have essentially the following in Build.PL:
> 
> | my $build = $class->new(
> |     ...
> |     install_path    => {
> |         ...
> |         'etc-global'    => '/etc'
> |     },
> |     misc_files      => {
> |         'misc/foo-bar'  => 'etc-global/foo/bar'
> |     },
> |     ...
> | );
> | 
> | $build->add_build_element('misc');
> 
> The intent is to install misc/foo-bar to /etc/foo/bar (with /etc/foo/ 
> belonging to another package and bar being a hook script), which basically 
> works ok.  misc/foo-bar has the executable bit set, however when the file 
> is copied to blib/etc-global/foo/bar, the x bit gets lost.
> 
> Is that by design?  If not, I hope this can be fixed before the release of 
> 0.28.

Hi Julian,

I haven't had time to look into this at yet, but I wanted to let you 
know you haven't been warnocked. I'll try to look at this issue sometime 
over the weekend.

Randy.

> Julian.
> 
> References:
>  1. http://rt.cpan.org/Ticket/Display.html?id=8190
>  2. http://sourceforge.net/mailarchive/message.php?msg_id=11494869

[Module::Build] Re: Smoke [5.9.4] 27656 FAIL(F) MSWin32 WinXP/.Net SP2 (x86/2 cpu)

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

Steve Hay wrote:
> Randy W. Sims wrote:
>> Ok, I finally got around to looking. The problem is where I suspected: 
>> It's the quoting of the macros VERSION & XS_VERSION. On the command 
>> line you can type:
>>
>>  bcc32 -DVERSION=\"1.01\" test.c
>>
>> But we use response files for all compilers on Windows (GCC, BCC, & 
>> MSVC), and the response files seem to require a different quoting 
>> syntax that I haven't figured out yet.
[...]

>> I've posted on one of the borland newsgroups see if anyone can help 
>> there. If I can't find a quoting solution, I guess I can move macros 
>> of the key=value form back onto the commandline, for bcc.
> 
> I get the same problems here.  I found that you can use "configuration 
> files" (like "response files", but they only contain compiler options, 
> not filenames too) and that these work, but you can only seem to have 
> one of them.
[...]

> That just makes it all the more irritating that the same quoting doesn't 
> work in response files.

Extremely irritating. I've received several responses to my query in the 
Borland newsgroups, but no solution. I'm left with the alternative of 
pulling them out of the response file for that compiler.

The attached patch is what I've checked into our repository. Tests now pass.

Randy.

Re: [Module::Build] PERL_MM_USE_DEFAULT

[Yitzchak Scott-T. <sth...@ef...>]

On Thu, Apr 06, 2006 at 03:57:07PM -0400, Randy W. Sims wrote:
> Tyler MacDonald wrote:
> >Yitzchak Scott-Thoennes <sth...@ef...> wrote:
> >
> >>The problem that I tried to address is module authors not giving a
> >>default and not realizing that this dies when you try to do an
> >>unattended install.  I want to force a default so they don't have
> >>the option to unknowingly cause some users a problem.
> >
> >
> >	This is a problem with CPAN.pm as well; if you try to do the initial
> >setup with PERL_MM_USE_DEFAULT=1, it loops forever on the "Select a mirror"
> >prompt. :-/ I've been meaning to discuss this more / submit a patch, but my
> >backlog has been insane lately...
> 
> We can:
> 
> die "ERROR: This build script not safe for unattended installs. Please 
> notify @{[$self->dist_author]} that they wrote a bad bad Build.PL. 
> Please ask them to provide reasonable defaults or switch to the new 
> ask() method."
>   if $ENV{PERL_MM_USE_DEFAULT}
>   && (called_without_default(y_n) || called_without_default(prompt);
> 
> __END__

That sounds like as good as it's going to get.

Re: [Module::Build] PERL_MM_USE_DEFAULT

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

Randy W. Sims <ml...@th...> wrote:
> >	This is a problem with CPAN.pm as well; if you try to do the initial
> >setup with PERL_MM_USE_DEFAULT=1, it loops forever on the "Select a mirror"
> >prompt. :-/ I've been meaning to discuss this more / submit a patch, but my
> >backlog has been insane lately...
> We can:
> 
> die "ERROR: This build script not safe for unattended installs. Please 
> notify @{[$self->dist_author]} that they wrote a bad bad Build.PL. 
> Please ask them to provide reasonable defaults or switch to the new 
> ask() method."
>   if $ENV{PERL_MM_USE_DEFAULT}
>   && (called_without_default(y_n) || called_without_default(prompt);

	Sure. What I really want though, is for CPAN.pm to be totally
automatable. If you want a good chuckle, check out the attached
hackety-hackety-hack I whipped together one afternoon to do an autobuild;
the scary thing is it actually works. <g>

	- Tyler

Re: [Module::Build] Document install_base_relpaths

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

On Apr 6, 2006, at 10:53, Randy W. Sims wrote:

> Great. besides making the methods public and documenting them, the  
> bigger change was one you don't see: During install it now knows to  
> install the custom type whereas before it would not install them  
> unless you specified an explicit --install-path or did some  
> trickery under the hood. Eg. setting install_base_relpath and  
> giving the --install-base option did nothing when installing.

So if I don't set install-path or install_base, where will it be  
installed? I thought that I needed to write process_[element]_files()  
to set it up to do the right thing. For example, for my "www"  
element, I have this method:

sub process_www_files {
     my $self  = shift;
     my $files = $self->find_www_files;
     while (my ($file, $dest) = each %$files) {
         $self->copy_if_modified(
             from => $file,
             to => File::Spec->catfile($self->blib, $dest)
         );
     }
}

Do I no longer need that?

Best,

Daviid

Re: [Module::Build] PERL_MM_USE_DEFAULT

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

Tyler MacDonald wrote:
> Yitzchak Scott-Thoennes <sth...@ef...> wrote:
> 
>>The problem that I tried to address is module authors not giving a
>>default and not realizing that this dies when you try to do an
>>unattended install.  I want to force a default so they don't have
>>the option to unknowingly cause some users a problem.
> 
> 
> 	This is a problem with CPAN.pm as well; if you try to do the initial
> setup with PERL_MM_USE_DEFAULT=1, it loops forever on the "Select a mirror"
> prompt. :-/ I've been meaning to discuss this more / submit a patch, but my
> backlog has been insane lately...

We can:

die "ERROR: This build script not safe for unattended installs. Please 
notify @{[$self->dist_author]} that they wrote a bad bad Build.PL. 
Please ask them to provide reasonable defaults or switch to the new 
ask() method."
   if $ENV{PERL_MM_USE_DEFAULT}
   && (called_without_default(y_n) || called_without_default(prompt);

__END__

Re: [Module::Build] PERL_MM_USE_DEFAULT

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

Yitzchak Scott-Thoennes <sth...@ef...> wrote:
> The problem that I tried to address is module authors not giving a
> default and not realizing that this dies when you try to do an
> unattended install.  I want to force a default so they don't have
> the option to unknowingly cause some users a problem.

	This is a problem with CPAN.pm as well; if you try to do the initial
setup with PERL_MM_USE_DEFAULT=1, it loops forever on the "Select a mirror"
prompt. :-/ I've been meaning to discuss this more / submit a patch, but my
backlog has been insane lately...

	Cheers,
		Tyler

Re: [Module::Build] PERL_MM_USE_DEFAULT

[Yitzchak Scott-T. <sth...@ef...>]

On Thu, Apr 06, 2006 at 08:17:24PM +0200, demerphq wrote:
> On 4/6/06, Randy W. Sims <ml...@th...> wrote:
> > Yitzchak Scott-Thoennes wrote:
> > > On Tue, Mar 07, 2006 at 05:33:49AM -0500, Randy W. Sims wrote:
> > >
> > >>Sorry for responding late to this, but won't this break exististing
> > >>distributions? Distros that currently use y_n() without defaults will
> > >>start die-ing when users upgrade M::B.
> >
> > > It doesn't break them in the sense that they were already broken for some users.  But maybe it would be better to pick an arbitrary default?
> >
> > I don't think there is a reasonable default. I think the only way around
> > the issue is to create new methods and deprecate the older ones or not
> > require defaults. It's not reasonable to have Build scripts failing just
> > because a user upgrades to a new version of Module::Build.
> >
> > This needs to be resolved before 0.28. Any other ideas for solutions?
> 
> Maybe sse the "version trick".
> 
> IOW, if the user says
> 
>    use Module::Build VERSION;
> 
> then you kick in the special behaviour (dying if no default). If they
> dont then you leave it.

The problem that I tried to address is module authors not giving a
default and not realizing that this dies when you try to do an
unattended install.  I want to force a default so they don't have
the option to unknowingly cause some users a problem.

Re: [Module::Build] .modulebuildrc documentation out of sync with code

[David G. <da...@hy...>]

Randy W. Sims wrote:
> Instead of search for the first valid "HOME" directory, we should 
> probably be looking for the first one that contains the file we need 
> since all of the directories usually exist.

Agreed

> I'm not sure about the order of the search. I would put "HOME" first 
> because if it is explicitly set (esp on Windows), then it is probably 
> intended to be the "primary" home dir.

I'd put HOME first because it's more consistent and as long as there's 
automatic fall back, it won't really matter for people on Windows.

David

Re: [Module::Build] .modulebuildrc documentation out of sync with code

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

On Apr 6, 2006, at 1:21 PM, Randy W. Sims wrote:

> David Golden wrote:
>> I posted this to RT, but I'll copy here as well:
>> Documentation for the location of .modulebuildrc  
>> says .modulebuildrc should be placed in $ENV{HOME}, but the code  
>> actually searches the following environment variables: APPDATA  
>> HOME USERPROFILE WINDIR SYS$LOGIN.
>> This is particularly confusing because HOME isn't listed first, so a
>> .modulebuildrc file place in $ENV{HOME} just mysteriously fails to  
>> work
>> on Win32 where $ENV{APPDATA} exists.
>
> Instead of search for the first valid "HOME" directory, we should  
> probably be looking for the first one that contains the file we  
> need since all of the directories usually exist.

Agreed.

> I'm not sure about the order of the search. I would put "HOME"  
> first because if it is explicitly set (esp on Windows), then it is  
> probably intended to be the "primary" home dir.

Sounds reasonable.  I think it's generally unlikely that people will  
have more than one .modulebuildrc so I'm not too worried about  
getting The Perfect Order.

  -Ken

Re: [Module::Build] .modulebuildrc documentation out of sync with code

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

David Golden wrote:
> I posted this to RT, but I'll copy here as well:
> 
> Documentation for the location of .modulebuildrc says .modulebuildrc 
> should be placed in $ENV{HOME}, but the code actually searches the 
> following environment variables: APPDATA HOME USERPROFILE WINDIR SYS$LOGIN.
> 
> This is particularly confusing because HOME isn't listed first, so a
> .modulebuildrc file place in $ENV{HOME} just mysteriously fails to work
> on Win32 where $ENV{APPDATA} exists.

Instead of search for the first valid "HOME" directory, we should 
probably be looking for the first one that contains the file we need 
since all of the directories usually exist.

I'm not sure about the order of the search. I would put "HOME" first 
because if it is explicitly set (esp on Windows), then it is probably 
intended to be the "primary" home dir.

Having trouble finding the original report though that led to the above 
search being added, so I'm not sure of the exact problem it was intended 
to solve. I don't want to break anything.

Randy.

Re: [Module::Build] PERL_MM_USE_DEFAULT

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

On 4/6/06, Randy W. Sims <ml...@th...> wrote:
> Yitzchak Scott-Thoennes wrote:
> > On Tue, Mar 07, 2006 at 05:33:49AM -0500, Randy W. Sims wrote:
> >
> >>Sorry for responding late to this, but won't this break exististing
> >>distributions? Distros that currently use y_n() without defaults will
> >>start die-ing when users upgrade M::B.
>
> > It doesn't break them in the sense that they were already broken for so=
me users.  But maybe it would be better to pick an arbitrary default?
>
> I don't think there is a reasonable default. I think the only way around
> the issue is to create new methods and deprecate the older ones or not
> require defaults. It's not reasonable to have Build scripts failing just
> because a user upgrades to a new version of Module::Build.
>
> This needs to be resolved before 0.28. Any other ideas for solutions?

Maybe sse the "version trick".

IOW, if the user says

   use Module::Build VERSION;

then you kick in the special behaviour (dying if no default). If they
dont then you leave it.

Cheers,
Yves

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

Re: [Module::Build] Document install_base_relpaths

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

David Wheeler wrote:
> On Apr 6, 2006, at 03:54, Randy W. Sims wrote:
> 
>> David, could you let me know if this provides a solid interim  
>> solution to the issues you've brought up. The repository has now  
>> moved to a subversion repository at <https://svn.perl.org/modules/ 
>> Module-Build/> if you want to check it out.
> 
> 
> Yeah, looks great. I was able to patch my subclass thusly:

Great. besides making the methods public and documenting them, the 
bigger change was one you don't see: During install it now knows to 
install the custom type whereas before it would not install them unless 
you specified an explicit --install-path or did some trickery under the 
hood. Eg. setting install_base_relpath and giving the --install-base 
option did nothing when installing.

Thanks,
Randy.