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

[Module::Build] Re: Module::Build and installing in non-standard locations

[Matisse E. <ma...@ma...>]

On Tue, 28 Mar 2006, Randy W. Sims wrote:

> There are a number of ways to do this. The most simple is:
> 
> use strict;
> use warnings;
> 
> use File::HomeDir;
> my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' );
> 
> use Module::Build;
> my $builder = Module::Build->new(
>      module_name  => 'Foo',
>      license      => 'perl',
> 
>      conf_files => {
>          'etc/httpd.conf' => 'conf/httpd.conf',
>      },
> 
>      install_path => {
>          'conf' => $conf_dir,
>      },
> );
> 
> $builder->add_build_element( 'conf' );
> 
> $builder->create_build_script();
> 
> __END__

I haven't been able to get this approach to work.

The file(s) from the new build_element *do* get copied into blib, so in 
the above example   httpd.conf   gets copied to  blib/conf/httpd.conf
but, when i do     Build install    it does not get installed.

I looked in   _build/build_params   and the   install_path  hash
does contain an entry for my new build element(s), but nothing gets 
installed there when I run  ./Build install  (and  ./Build fakesinstall  
doesn't show the files either.)

-M

[Module::Build] Module requirements (was: Module::Build and installing in non-standard locations)

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

Adam Kennedy wrote:
 >> There are a number of ways to do this. The most simple is:
 >>
 >> use strict;
 >> use warnings;
 >>
 >> use File::HomeDir;
 >> my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' );
 >
 >
 > Not that I wish to be a pedant about this, but only so people keep it in
 > mind...
 >
 > This installer will crash with a non-useful error message if someone
 > tries to install of < 5.006, and has an implicit undeclared (still
 > unresolvable I believe) dependency on File::HomeDir.

How is this different from a Makefile.PL or any other perl script with a 
C<use> statement. If the C<use>d module can't be found, it says it can't 
be found. It doesn't crash.

Sure, the dependency should be listed in META.yml. And, there is a way 
to that so that CPAN.pm and other tools can see the dependency before 
running the Build.PL: You simply list it in C<requres> argument to the 
constructor. But this was just a simplified example to illustrate a 
different point...

 > (I'll shut up about the whole implicit undeclared unresolvable
 > dependency on Module::Build for a while, given it's now in the core and
 > I've had a good long chat about the issue with Tony.)

Again, how is this different from MakeMaker's Makefile.PL which, strange 
enough, requires MakeMaker to be present?

 > So if you use warnings in your Build.PL you should always do it as
 >
 > use 5.006;
 > use strict;
 > use warnings;

I agree, this is true of any script, not just Build.PL.

 > As for how to ensure File::HomeDir is installed before you actually know
 > what you dependencies are, well I dunno, but this problem is going to
 > keep coming back and haunting us till MB supports bundling of some kind.

Bundling is *a* solution to *some* problems *some* of the time. From 
what I understand there's a pretty good module out there that helps with 
that ;). But I'm not yet convinced that it should be the default method 
for every distribution. Authors should have a choice. For people who 
want to bundle Module::Build it's simple to do by hand, and it's been 
done by authors who decided that was best for their distribution.

Regards,
Randy.

[Module::Build] Re: New Module::Build released

[Rafael Garcia-S. <rga...@ma...>]

Randy W. Sims wrote:
> 
> If there is, I was never able to find it. I started to write one, but 
> it's not simple to write a generic one. For ex. MB has to be built first 
> and the generated M::B::ConfigData copied. I don't know if other 
> dual-life modules have similar generated files or exceptions. I guess 
> with the limited number of modules in core a few exceptions would be ok.

I don't think that's the case for other CPAN modules.
Currently M::B is in lib/, which means it has no Makefile.PL like
modules in ext/. However the config_data script is extracted from
utils/config_data.PL at the end of the build process.
How is ConfigData.pm generated actually ?

> I put together diffs and tested them last night when I saw the version 
> bump, so I'll go ahead and post them.
> 
> eucb.diff upgrades ExtUtils::CBuilder to 0.18
> mb.diff upgrades Module::Build to 0.27_10

Both applied as #27631, thanks.

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

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

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.

  -Ken

[Module::Build] Yet Another Documentation Split

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

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?

Randy.

[Module::Build] Re: New Module::Build released

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

Ken Williams wrote:
> Hi,
> 
> Last night I released Module-Build-0.27_10 to CPAN.  It vanquishes a  
> number of scary-looking warnings when building bleadperl on OS X.  I  
> believe it also solves some build errors for Win32.  I recommend it  
> gets integrated into bleadperl.
> 
>  -Ken
> 
> p.s. - I've been assuming that publishing to CPAN and requesting an  
> integration is the right procedure, because there's some magical  script 
> out there to schlurp up CPAN releases into blead, right?

If there is, I was never able to find it. I started to write one, but 
it's not simple to write a generic one. For ex. MB has to be built first 
and the generated M::B::ConfigData copied. I don't know if other 
dual-life modules have similar generated files or exceptions. I guess 
with the limited number of modules in core a few exceptions would be ok.

I put together diffs and tested them last night when I saw the version 
bump, so I'll go ahead and post them.

eucb.diff upgrades ExtUtils::CBuilder to 0.18
mb.diff upgrades Module::Build to 0.27_10

Randy.

Re: [Module::Build] New Module::Build released

[John P. <jpe...@ro...>]

Ken Williams wrote:
> p.s. - I've been assuming that publishing to CPAN and requesting an 
> integration is the right procedure, because there's some magical script 
> out there to schlurp up CPAN releases into blead, right?

I believe that script is named ./Rafael ;-)

I've always provided diff's (cause it's easy enough to generate from my 
local bleadperl mirror) to save time, but since this is just a file by 
file replacement, I suspect a diff isn't any easier for him to manage...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

[Module::Build] New Module::Build released

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

Hi,

Last night I released Module-Build-0.27_10 to CPAN.  It vanquishes a  
number of scary-looking warnings when building bleadperl on OS X.  I  
believe it also solves some build errors for Win32.  I recommend it  
gets integrated into bleadperl.

  -Ken

p.s. - I've been assuming that publishing to CPAN and requesting an  
integration is the right procedure, because there's some magical  
script out there to schlurp up CPAN releases into blead, right?

Re: [PATCH] Re: [Module::Build] Making 0.28 a reality

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

Thanks, I've applied both patches.

  -Ken


On Mar 29, 2006, at 1:49 AM, Yitzchak Scott-Thoennes wrote:

> On Tue, Mar 28, 2006 at 11:34:03PM -0800, Yitzchak Scott-Thoennes  
> wrote:
>> That build_requires on Test::More is erroneous, since it is bundled
>> in the distribution.  It should be removed:  (untested)
>>
>> --- Build.PL.orig	2006-01-20 11:29:18.898665000 -0800
>> +++ Build.PL	2006-03-28 23:32:38.812500000 -0800
>> @@ -43,9 +43,6 @@
>>  		  'Pod::Readme' => 0.04,
>>  		  'Module::Signature' => 0.21,
>>  		 },
>> -   build_requires => {
>> -		      'Test::More' => 0,
>> -		     },
>>     sign => 1,
>>     create_readme => 1,
>
> And now that I look at it, these definitely should be added:
>
> --- Build.PL.orig	2006-01-20 11:29:18.898665000 -0800
> +++ Build.PL	2006-03-28 23:45:28.218750000 -0800
> @@ -39,13 +39,12 @@
>  	       },
>     recommends => {
>  		  'Archive::Tar' => '1.08',
> +		  'ExtUtils::CBuilder' => 0.15,
> +		  'ExtUtils::ParseXS' => 1.02,
>  		  'ExtUtils::Install' => 0.30,
>  		  'Pod::Readme' => 0.04,
>  		  'Module::Signature' => 0.21,
>  		 },
> -   build_requires => {
> -		      'Test::More' => 0,
> -		     },
>     sign => 1,
>     create_readme => 1,
>
>
>
> -------------------------------------------------------
> 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-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

Re: [Module::Build] Making 0.28 a reality

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

On Mar 28, 2006, at 10:57 PM, Stephen Adkins wrote:

> Module::Build has the following dependencies.
>
> requires:
>   Cwd: 0
>   Data::Dumper: 0
>   ExtUtils::Install: 0
>   ExtUtils::Manifest: 0
>   ExtUtils::Mkbootstrap: 0
>   File::Basename: 0
>   File::Compare: 0
>   File::Copy: 0
>   File::Find: 0
>   File::Path: 0
>   File::Spec: 0.82
>   Getopt::Long: 0
>   IO::File: 0
>   Test::Harness: 0
>   Text::ParseWords: 0
>   perl: 5.005_03
> build_requires:
>   Test::More: 0
> recommends:
>   Archive::Tar: 1.08
>   ExtUtils::Install: 0.3
>   Module::Signature: 0.21
>   Pod::Readme: 0.04


I know that list looks long, but so far we only have required  
dependencies which are part of core for perl 5.6.0, and also possible  
to install on perl 5.005_03.  So it's not as bad as it looks.

  -Ken

Re: [Module::Build] Making 0.28 a reality

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

On Mar 28, 2006, at 10:57 PM, Stephen Adkins wrote:

> The two full implementations of YAML in perl are YAML (i.e. YAML.pm)
> and YAML::Syck.  Neither of them has significant other dependencies.
>
>    YAML - build_requires: Test::Base: 0.49
>                requires: perl 5.6.1
>
>    YAML::Syck - build requires a C compiler
>                requires: perl 5.003
>

You must be joking!  Perl 5.6.1 and a C compiler are VERY significant  
dependencies.  M::B is pure-perl back to 5.005 quite deliberately.   
Except for Test::More, every one of M::B's required modules has been  
bundled with Perl itself since 5.005.

   % corelist Cwd Data::Dumper ExtUtils::Install ExtUtils::Manifest  
ExtUtils::Mkbootstrap File::Basename File::Compare File::Copy  
File::Find File::Path File::Spec Getopt::Long IO::File Test::Harness  
Text::ParseWords Test::More
   Cwd  was first released with perl 5
   Data::Dumper  was first released with perl 5.005
   ExtUtils::Install  was first released with perl 5.002
   ExtUtils::Manifest  was first released with perl 5.001
   ExtUtils::Mkbootstrap  was first released with perl 5.001
   File::Basename  was first released with perl 5
   File::Compare  was first released with perl 5.004
   File::Copy  was first released with perl 5.002
   File::Find  was first released with perl 5
   File::Path  was first released with perl 5.001
   File::Spec  was first released with perl 5.005
   Getopt::Long  was first released with perl 5
   IO::File  was first released with perl 5.00307
   Test::Harness  was first released with perl 5
   Text::ParseWords  was first released with perl 5
   Test::More  was first released with perl 5.007003

> The only reason to have *another* external YAML distribution is to
> have one which
> has even fewer dependencies (i.e. perl 5.005_03 aka 5.5.3, no C  
> compiler).

Yes, that's it exactly.

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: [PATCH] Re: [Module::Build] Making 0.28 a reality

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

On Tue, Mar 28, 2006 at 11:34:03PM -0800, Yitzchak Scott-Thoennes wrote:
> That build_requires on Test::More is erroneous, since it is bundled
> in the distribution.  It should be removed:  (untested)
> 
> --- Build.PL.orig	2006-01-20 11:29:18.898665000 -0800
> +++ Build.PL	2006-03-28 23:32:38.812500000 -0800
> @@ -43,9 +43,6 @@
>  		  'Pod::Readme' => 0.04,
>  		  'Module::Signature' => 0.21,
>  		 },
> -   build_requires => {
> -		      'Test::More' => 0,
> -		     },
>     sign => 1,
>     create_readme => 1,

And now that I look at it, these definitely should be added:

--- Build.PL.orig	2006-01-20 11:29:18.898665000 -0800
+++ Build.PL	2006-03-28 23:45:28.218750000 -0800
@@ -39,13 +39,12 @@
 	       },
    recommends => {
 		  'Archive::Tar' => '1.08',
+		  'ExtUtils::CBuilder' => 0.15,
+		  'ExtUtils::ParseXS' => 1.02,
 		  'ExtUtils::Install' => 0.30,
 		  'Pod::Readme' => 0.04,
 		  'Module::Signature' => 0.21,
 		 },
-   build_requires => {
-		      'Test::More' => 0,
-		     },
    sign => 1,
    create_readme => 1,
 

Re: [Module::Build] Making 0.28 a reality

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

On Tue, Mar 28, 2006 at 11:57:24PM -0500, Stephen Adkins wrote:
> The two full implementations of YAML in perl are YAML (i.e. YAML.pm)
> and YAML::Syck.  Neither of them has significant other dependencies.
> 
>    YAML - build_requires: Test::Base: 0.49
>                requires: perl 5.6.1

YAML bundles Test::Base and shouldn't be listing it in build_requires.
I thought Ingy was going to fix that.
 
>    YAML::Syck - build requires a C compiler
>                requires: perl 5.003
> 
> http://search.cpan.org/src/INGY/YAML-0.58/META.yml
> http://search.cpan.org/src/AUTRIJUS/YAML-Syck-0.38/META.yml

[PATCH] Re: [Module::Build] Making 0.28 a reality

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

On Tue, Mar 28, 2006 at 11:57:24PM -0500, Stephen Adkins wrote:
> Is the reason Module::Build can't depend on YAML because it depends on
> perl 5.6.1
> and Module::Build seeks to support (depend on only) perl 5.5.3?

No.
 
> Module::Build has the following dependencies.
> 
> requires:
>   Cwd: 0
>   Data::Dumper: 0
>   ExtUtils::Install: 0
>   ExtUtils::Manifest: 0
>   ExtUtils::Mkbootstrap: 0
>   File::Basename: 0
>   File::Compare: 0
>   File::Copy: 0
>   File::Find: 0
>   File::Path: 0
>   File::Spec: 0.82
>   Getopt::Long: 0
>   IO::File: 0
>   Test::Harness: 0
>   Text::ParseWords: 0
>   perl: 5.005_03
> build_requires:
>   Test::More: 0
> recommends:
>   Archive::Tar: 1.08
>   ExtUtils::Install: 0.3
>   Module::Signature: 0.21
>   Pod::Readme: 0.04
> 
> http://search.cpan.org/src/KWILLIAMS/Module-Build-0.27_09/META.yml

Cwd  was first released with perl 5
Data::Dumper  was first released with perl 5.005
ExtUtils::Install  was first released with perl 5.002
ExtUtils::Manifest  was first released with perl 5.001
ExtUtils::Mkbootstrap  was first released with perl 5.001
File::Basename  was first released with perl 5
File::Compare  was first released with perl 5.004
File::Copy  was first released with perl 5.002
File::Find  was first released with perl 5
File::Path  was first released with perl 5.001
File::Spec  was first released with perl 5.005
Getopt::Long  was first released with perl 5
IO::File  was first released with perl 5.00307
Test::Harness  was first released with perl 5
Text::ParseWords  was first released with perl 5
Test::More  was first released with perl 5.007003

That build_requires on Test::More is erroneous, since it is bundled
in the distribution.  It should be removed:  (untested)

--- Build.PL.orig	2006-01-20 11:29:18.898665000 -0800
+++ Build.PL	2006-03-28 23:32:38.812500000 -0800
@@ -43,9 +43,6 @@
 		  'Pod::Readme' => 0.04,
 		  'Module::Signature' => 0.21,
 		 },
-   build_requires => {
-		      'Test::More' => 0,
-		     },
    sign => 1,
    create_readme => 1,
 

> The only reason to have *another* external YAML distribution is to
> have one which
> has even fewer dependencies (i.e. perl 5.005_03 aka 5.5.3, no C compiler).
> 
> Some possible names for the module...
> 
>    YAML::Simple
>    YAML::Portable
> 
> If a YAML::Simple existed (which implemented a sufficient subset of
> the YAML spec),
> would this significantly improve the dependency characteristics of the
> tool chain?

If possible, it would be better to make YAML itself work on 5.005_03
than to create a YAML::Simple.  But neither satisfies the goal of
having M::B have no non-core dependencies.

Re: [Module::Build] Making 0.28 a reality

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

> Well, yes and no.  Why are useful bits like ExtUtils::Manifest split
> off?  Why are we trying to get ExtUtils::Install split off from
> ExtUtils::MakeMaker?   I don't think that all of M::B functionality has
> to be contained within the M::B distribution -- well packaged, reusable
> dependencies should be OK.  My point (in response to something else in
> the email thread) was that bundling stuff into M::B to minimize
> dependencies isn't enough.
...
> I'd rather see a Module::MetaYaml split off like ExtUtils::Manifest if
...
> David Golden

Hi,

The two full implementations of YAML in perl are YAML (i.e. YAML.pm)
and YAML::Syck.  Neither of them has significant other dependencies.

   YAML - build_requires: Test::Base: 0.49
               requires: perl 5.6.1

   YAML::Syck - build requires a C compiler
               requires: perl 5.003

http://search.cpan.org/src/INGY/YAML-0.58/META.yml
http://search.cpan.org/src/AUTRIJUS/YAML-Syck-0.38/META.yml

What is not "well packaged" about these two distributions?

Is the reason Module::Build can't depend on YAML because it depends on
perl 5.6.1
and Module::Build seeks to support (depend on only) perl 5.5.3?

Module::Build has the following dependencies.

requires:
  Cwd: 0
  Data::Dumper: 0
  ExtUtils::Install: 0
  ExtUtils::Manifest: 0
  ExtUtils::Mkbootstrap: 0
  File::Basename: 0
  File::Compare: 0
  File::Copy: 0
  File::Find: 0
  File::Path: 0
  File::Spec: 0.82
  Getopt::Long: 0
  IO::File: 0
  Test::Harness: 0
  Text::ParseWords: 0
  perl: 5.005_03
build_requires:
  Test::More: 0
recommends:
  Archive::Tar: 1.08
  ExtUtils::Install: 0.3
  Module::Signature: 0.21
  Pod::Readme: 0.04

http://search.cpan.org/src/KWILLIAMS/Module-Build-0.27_09/META.yml

The only reason to have *another* external YAML distribution is to
have one which
has even fewer dependencies (i.e. perl 5.005_03 aka 5.5.3, no C compiler).

Some possible names for the module...

   YAML::Simple
   YAML::Portable

If a YAML::Simple existed (which implemented a sufficient subset of
the YAML spec),
would this significantly improve the dependency characteristics of the
tool chain?

Stephen

Re: [Module::Build] Making 0.28 a reality

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

Ken Williams wrote:
> 
> On Mar 28, 2006, at 2:16 PM, David Golden wrote:
>>
>> It doesn't really matter if M::B is self-contained or not if the other 
>> parts of the toolchain are fouled up.
> 
> No, it does matter.

Well, yes and no.  Why are useful bits like ExtUtils::Manifest split 
off?  Why are we trying to get ExtUtils::Install split off from 
ExtUtils::MakeMaker?   I don't think that all of M::B functionality has 
to be contained within the M::B distribution -- well packaged, reusable 
dependencies should be OK.  My point (in response to something else in 
the email thread) was that bundling stuff into M::B to minimize 
dependencies isn't enough.

I'd rather see a Module::MetaYaml split off like ExtUtils::Manifest if 
it could become the nucleus of something that might grow to help other 
parts of the toolchain rather than keeping it "locked up" inside the 
Module::Build distribution.

To the broader point Ken made, I totally agree that M::B doesn't need to 
solve the rest of the toolchain's problems.

David Golden

[Module::Build] Re: Module::Build and installing in non-standard locations

[Matisse E. <ma...@ma...>]

On Tue, 28 Mar 2006, Randy W. Sims wrote:

> The add_build_element() method is the key to the process.

Ah-Ha and thank you Very Nice!

I did read the perldoc - but just didn't get that
   add_build_element('foo_files')
would make M::B look for a  foo_fiels element - and I thought i would have 
to provide a   process_foo_files()  method, I did not realize that I 
didn't have to do that part (the documentation seems to say I had to.)

> Since we use ExtUtils::Install to install there is currently no way to 
> specifiy the file mode.

I'll find some way to live with that for now :-)
It's mainly an issue for executables.
 
> This has turned out to be one of the most FAQ with Module::Build. There 
> are plans to greatly simplify the process in the next version of M::B, 
> including removing the above mentioned limitations.

Cool, and thanks again.

-Matisse

Re: [Module::Build] Making 0.28 a reality

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

On Mar 28, 2006, at 2:16 PM, David Golden wrote:

> However, the latest Bundle::CPAN includes YAML, which uses  
> Module::Install, requires 5.6.1 or better and build_requires  
> Test::Base, which itself requires Spiffy.
>
> So... when CPAN tells someone their CPAN is out of date and to  
> upgrade with Bundle::CPAN or when someone wants to upgrade CPAN for  
> some other reason -- for example, for better compatibility with  
> Module::Build -- they're in for a world of hurt if any of the  
> ballooning dependencies fail to build using the already installed  
> CPAN/installer toolchain.

I agree that this dependency chain is messed up and needs a  
solution.  Personally I'm leaving it to those folks to work out,  
though.  The tool we need for M::B is different than the one they need.


>
> It doesn't really matter if M::B is self-contained or not if the  
> other parts of the toolchain are fouled up.

No, it does matter.

  -Ken

[Module::Build] Re: Module::Build and installing in non-standard locations

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

Matisse Enzer wrote:
> What's the standard (if any) for how to configure a build script to 
> install specific files (e.g. httpd.conf) in someplace other than the 
> standard Perl library/script/man locations?
> 
> For example, if my distro contains a bunch of .pm files and .pl files, 
> which go in the "normal" place, and my distro also contains:
> 
>    app_startup.pl
>    httpd.conf
> 
> and I want those installed as:
> 
>    app_startup.pl   => "$some_dir/app-startup.pl",  # mode 555
>    httpd.conf       => "$some_other_dir/conf",      # mode 444
> 
> is there a good standardized way to do this?

There are a number of ways to do this. The most simple is:

use strict;
use warnings;

use File::HomeDir;
my $conf_dir = File::Spec->catdir( File::HomeDir->my_home, '.Foo' );

use Module::Build;
my $builder = Module::Build->new(
     module_name  => 'Foo',
     license      => 'perl',

     conf_files => {
         'etc/httpd.conf' => 'conf/httpd.conf',
     },

     install_path => {
         'conf' => $conf_dir,
     },
);

$builder->add_build_element( 'conf' );

$builder->create_build_script();

__END__

The add_build_element() method is the key to the process. It lets M::B 
know it should look for a 'conf_files' property that describes files to 
be copied from somewhere in your distribution to a directory in 'blib'. 
In the above example, 'etc/httpd.conf' in your distribution root to 
'blib/conf/httpd.conf'.

Note that it's a current limitation that the first element of the 
directory name in blib must be the same as the name of the build 
element, in this case 'conf'.

Next the 'install_path' is looked at for a path to install build 
elements of that type. The build elements will be copied from the 
directory in 'blib' to the directory given. It is not necessary to 
specify the 'install_path' here; it can be specified on the command line 
by the user when invoking the install action:

   ./Build install --install-path conf=/etc/

If specified on the command line it will override the constructor arg. 
If it is not specified in either place, those files will not be 
installed, so it can be used as a flag.

Since we use ExtUtils::Install to install there is currently no way to 
specifiy the file mode.

This has turned out to be one of the most FAQ with Module::Build. There 
are plans to greatly simplify the process in the next version of M::B, 
including removing the above mentioned limitations.

There are also several other more advanced ways to accomplish the above 
by creating a subclass and providing methods to enumerate the files you 
want to install or to create the files to be installed. There are 
examples of these in Module::Build::Cookbook.

Also, there is a list dedicated to Module::Build which I've CC'd.

Regards,
Randy.

Re: [Module::Build] Making 0.28 a reality

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

Yitzchak Scott-Thoennes wrote:
> On Mon, Mar 20, 2006 at 11:09:39PM -0500, David Golden wrote:
>> John Peacock wrote:
>>> I'm not Ken (nor do I play him on TV), but I'd actually suggest moving 
>>> the code to a new module Module::Build::YAML, both for clarity (to 
>>> separate the code for easier maintenance) as well as easier replacement 
>>> (M::B can try to use YAML and only if it isn't found switch to using 
>>> M::B::YAML instead).  It may be that at some time in the future it would 
>>> be useful to be able to /read/ YAML data (which requires the full YAML 
>>> distro) instead of just /writing/ YAML (which the compatibility layer 
>>> can handle nicely).
>> Any chance this could be generalized further to handle all the YAML that 
>> CPAN.pm needs and free us from the tyranny of YAML prerequisites?
>>
>> Module::MetaYAML?
> 
> The point of not just requiring the "real" YAML is to keep a low-level
> module-builder (Module::Build) from requiring other distributions.
> This doesn't apply to CPAN, and separating out a Module::MetaYAML
> would defeat this purpose for MB.

However, the latest Bundle::CPAN includes YAML, which uses 
Module::Install, requires 5.6.1 or better and build_requires Test::Base, 
which itself requires Spiffy.

So... when CPAN tells someone their CPAN is out of date and to upgrade 
with Bundle::CPAN or when someone wants to upgrade CPAN for some other 
reason -- for example, for better compatibility with Module::Build -- 
they're in for a world of hurt if any of the ballooning dependencies 
fail to build using the already installed CPAN/installer toolchain.

It doesn't really matter if M::B is self-contained or not if the other 
parts of the toolchain are fouled up.

David

Re: [Module::Build] Making 0.28 a reality

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

On Mon, Mar 20, 2006 at 11:09:39PM -0500, David Golden wrote:
> John Peacock wrote:
> >I'm not Ken (nor do I play him on TV), but I'd actually suggest moving 
> >the code to a new module Module::Build::YAML, both for clarity (to 
> >separate the code for easier maintenance) as well as easier replacement 
> >(M::B can try to use YAML and only if it isn't found switch to using 
> >M::B::YAML instead).  It may be that at some time in the future it would 
> >be useful to be able to /read/ YAML data (which requires the full YAML 
> >distro) instead of just /writing/ YAML (which the compatibility layer 
> >can handle nicely).
> 
> Any chance this could be generalized further to handle all the YAML that 
> CPAN.pm needs and free us from the tyranny of YAML prerequisites?
> 
> Module::MetaYAML?

The point of not just requiring the "real" YAML is to keep a low-level
module-builder (Module::Build) from requiring other distributions.
This doesn't apply to CPAN, and separating out a Module::MetaYAML
would defeat this purpose for MB.

Re: [Module::Build] Buglet: Creative use of $VERSION confuses M::B

[John P. <jpe...@ro...>]

Julian Mehnle wrote:
> No, at least not until version.pm support is fully working.  (Will that be 
> in 0.28?  And will 0.28 be out soon?)

version.pm support will be post 0.28 (we gotta cut things off at some 
point).  Ken has, I believe, stated that we are feature-frozen for 0.28 
and as soon as the bleadperl integration stops leaking blue smoke, then 
0.28 would be cut.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

Re: [Module::Build] Buglet: Creative use of $VERSION confuses M::B

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

Randy W. Sims wrote:
> Ken Williams wrote:
> > Johan Vromans wrote:
> > > Probably the best pseudo-solution to this pseudo-parsing problem is
> > > to stop parsing after the first successful assignment, and put a
> > > remark in the documentation.
> >
> > I believe that's what we actually do now, in the latest beta versions.
>
> It is except for one location when a fully-qualified package name is
> used: $Foo::Bar::VERSION vs $VERSION
>
> I can fix that, or I can allow successive expressions involving the same
> VERSION. I already put together a patch for it. It would allow arbitrary
> expressions like
>
> $VERSION =3D '1.01';
> $VERSION =3D $VERSION + 1;
> $VERSION +=3D 2;
> [...]

No, at least not until version.pm support is fully working.  (Will that be=
=20
in 0.28?  And will 0.28 be out soon?)  Otherwise you'd break things like:

| our $VERSION =3D '1.099.001';  # fake version for META.yml/CPAN
| $VERSION =3D '1.099001';       # real numerical version

=2E..which has been a working work-around so far.

[Module::Build] Re: [Module-build-checkins] Module-Build/lib/Module/Build Base.pm,1.567,1.568

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

The 'distclean' action was failing on Windows with the new batch script, 
Build.bat. The Build.bat script must terminate normally in order to 
execute the appended cleanup command during 'realclean' and 'distclean'.

I'm not sure the fix below is the best one.

One alternative, would be modify the 'Build' script (and thus the 
Build.bat script) to wrap the call to dispatch in an eval, converting 
any die into a warn so that the script can terminate normally.

Another alternative is not to die at all during 'distcheck'

Thoughts?

Randy.

Randy W. Sims wrote:
> Update of /cvsroot/module-build/Module-Build/lib/Module/Build
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7957/lib/Module/Build
> 
> Modified Files:
> 	Base.pm 
> Log Message:
> The 'distclean' operation on Windows was failing because it runs 'distcheck' which dies when it finds extra or missing files. This didn't give the 'Build.bat' script a chance to delete itself. Now it warns if the 'distcheck' actions is invoked as a dependency of another action; otherwise, it dies as before.
> 
> Also, added 'Build.bat' to our MANIFEST.SKIP as well as the default generated MANIFEST.SKIP.
> 
> Index: Base.pm
> ===================================================================
> RCS file: /cvsroot/module-build/Module-Build/lib/Module/Build/Base.pm,v
> retrieving revision 1.567
> retrieving revision 1.568
> diff -u -d -r1.567 -r1.568
> --- Base.pm	28 Mar 2006 04:28:23 -0000	1.567
> +++ Base.pm	28 Mar 2006 11:06:07 -0000	1.568
> @@ -2717,12 +2717,19 @@
>  
>  sub ACTION_distcheck {
>    my ($self) = @_;
> -  
> +
>    require ExtUtils::Manifest;
>    local $^W; # ExtUtils::Manifest is not warnings clean.
>    my ($missing, $extra) = ExtUtils::Manifest::fullcheck();
> -  die "MANIFEST appears to be out of sync with the distribution\n"
> -    if @$missing || @$extra;
> +
> +  return unless @$missing || @$extra;
> +
> +  my $msg = "MANIFEST appears to be out of sync with the distribution\n";
> +  if ( $self->invoked_action eq 'distcheck' ) {
> +    die $msg;
> +  } else {
> +    warn $msg;
> +  }
>  }
>  
>  sub _add_to_manifest {

Re: [Module::Build] Buglet: Creative use of $VERSION confuses M::B

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

On Tue, Mar 28, 2006 at 12:47:12AM -0800, Yitzchak Scott-Thoennes wrote:
> On Mon, Mar 27, 2006 at 04:07:24PM +0100, Nick Ing-Simmons wrote:
> > Would writing if on one line: 
> > 
> >      if ($^W) { $Config::IniFiles::VERSION = $Config::IniFiles::VERSION; }
> > 
> > Suffice to hide it from the pseudo-parser?
> 
> If the goal is to get Config::IniFiles to work with M::B rather than the
> other way around, best just to make it:
> 
>   $Config::IniFiles::VERSION = $Config::IniFiles::VERSION = (qw($Revision: 2.38 $))[1];
> 
> in the first place.

Lest this be adopted by others unnecessarily, let me mention that
VERSION is exempted from the used only once warning since at least
5.6.0.