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

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

On Feb 15, 2006, at 1:00 PM, Rob Kinyon wrote:

> I may just be echoing commonly-held sentiment, but if 0.28 is being
> held up because there's a bug in CPANPLUS, that's annoying. Neither I
> nor anyone I know even uses CPANPLUS.

Neither I nor anyone I know even uses Solaris.  Nonetheless, I would  
not recommend shipping 0.28 if it were broken under Solaris  
(hypothetically speaking).

Just another CPANPLUS user,
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/)

[Module::Build] yaml_dump on version objects

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

Dear Perl YAML-heads:

I've been trying to integrate version objects into Module::Build (now 
that I have a pure Perl release) and everything works except that YAML 
emits lots of warnings when trying to dump version objects:

Use of uninitialized value in hash element at 
/usr/lib/perl5/site_perl/5.8.7/YAML.pm line 283.
Use of uninitialized value in string eq at 
/usr/lib/perl5/site_perl/5.8.7/YAML.pm line 291.
...blah...blah...blah...
--- !perl/YAML::Warning
code: YAML_DUMP_WARN_BAD_NODE_TYPE
msg: "Can't perform serialization for node type "
...

I've tried to implement a yaml_dump() sub in the class, but I cannot 
figure out how to use it (the commented out Bless line just croaks). 
I've attached my example code (which requires version).

TIA

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: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

[Rob K. <rob...@gm...>]

On 2/14/06, Ken Williams <ke...@ma...> wrote:
>
> On Feb 14, 2006, at 8:46 AM, Rob Kinyon wrote:
>
> > On 2/13/06, Ken Williams <ke...@ma...> wrote:
> >> nice solid way would be a major project.  We're scheduling it for the
> >> next big release, i.e. after 0.27_xx becomes 0.28xx.
> >
> > Is there a current plan for the 0.28 release? There are a number of
> > features that I would love to use, but I can't until 0.28 is released
> > ...
>
> The only thing we're waiting for is to fix the CPANPLUS bug in which
> installation error output doesn't get included in cpan-testers reports.
>   I'm not sure that's really going to happen right away though, because
> I can't get my tuits together for it.

I may just be echoing commonly-held sentiment, but if 0.28 is being
held up because there's a bug in CPANPLUS, that's annoying. Neither I
nor anyone I know even uses CPANPLUS.

I just want to start writing "use Module::Build 0.28;" at the top of
my Build.PL's and be done with it. :-)

Rob

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

On 2/14/06, Ken Williams <ke...@ma...> wrote:
>
> On Feb 14, 2006, at 8:46 AM, Rob Kinyon wrote:
>
> > On 2/13/06, Ken Williams <ke...@ma...> wrote:
> >> nice solid way would be a major project.  We're scheduling it for the
> >> next big release, i.e. after 0.27_xx becomes 0.28xx.
> >
> > Is there a current plan for the 0.28 release? There are a number of
> > features that I would love to use, but I can't until 0.28 is released
> > ...
>
> The only thing we're waiting for is to fix the CPANPLUS bug in which
> installation error output doesn't get included in cpan-testers reports.
>   I'm not sure that's really going to happen right away though, because
> I can't get my tuits together for it.
>
> Randy just wrote me a message saying similar, so I think we should just
> do the 0.28 release now.  We can make the version.pm and Build.bat
> changes right away afterwards, or if we get some patches in the next
> day or two I can put them in beforehand.

I though i did provide a patch for the Build.bat issue.

Yves

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

[Module::Build] How close is a 0.28 release of Module::Build?

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

DBIx::Migration::Directories 0.01 has reached CPAN:
	http://search.cpan.org/~CRAKRJACK/DBIx-Migration-Directories-0.01/

This module depends on features of Module::Build that are only available as
of 0.27_03 (use %INC to find where custom subclass really is), and possibly
a few changes from later versions. It looks like the dev releases since 0.27
have improve Module::Build a lot. Is there anything else that needs to be
done before 0.28?

	Thanks,
		Tyler



----- Forwarded message from Tyler MacDonald <ty...@yi...> -----
=46rom: Tyler MacDonald <ty...@yi...>
Subject: DBIx::Migration::Directories 0.01 released
To: dbi...@pe...

DBIx::Migration::Directories 0.01 has reached CPAN:
	http://search.cpan.org/~CRAKRJACK/DBIx-Migration-Directories-0.01/

DBIx::Migration::Directories provides you with a framework for managing
database schemas easily. You create a directory to hold your schema, then in
that directory create sub-directories containing the SQL code to install,
remove, upgrade, or downgrade your schema.

When asked to install, upgrade, or downgrade a database schema,
DBIx::Migration::Directories will look at these directories and attempt to
find the shortest path between two schema versions. It will then run the
entire upgrade code in one transaction, rolling back if the upgrade fails.
Multiple database schemas can be managed within one database.

Features:
    * Works with Postgres, MySQL, and SQLite2
    * Easily extensible for other database engines
    * Install, upgrade, remove, *or* downgrade database schemas
    * Easy binding of schema versions to perl modules
    * "_common" and "_generic" schemas avoid duplication of effort
    * Test framework that keeps your databases clean
    * Module::Build subclass makes it easy to install schema files

For more information, see:

http://search.cpan.org/~CRAKRJACK/DBIx-Migration-Directories-0.01/lib/DBIx/=
Migration/Directories.pod

and

http://search.cpan.org/~CRAKRJACK/DBIx-Migration-Directories-0.01/bin/migra=
te-database-schema

	Cheers,
		Tyler


----- End forwarded message -----

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

Chris Dolan <ch...@cl...> wrote:
> >>>	Well it would only clobber the file if it contained the
> >>>"auto-generated" line, so I think that's safe, but if you want to be
> >>>*really* paranoid, how about having the dist actions fail if you  
> >>>havent
> >>>specified a "create_makfile_pl" arg? (one of the exsitng ones or  
> >>>"skip").
> >>I just tested and CVS HEAD M::B happily overwrote a hand-made
> >>Makefile.PL when I added 'traditional' to Build.PL and ran "Build
> >>distdir".  Luckily, I had it in SVN so it was an easy restore.
> >
> >	But that's exactly what you asked it to do. ;-)
> >
> >	Seriously though, it sounds like having at least a loud warning "I
> >did not write this Makefile.PL, move it out of the way first" is  
> >worthwhile.
> >
> >		- Tyler
> 
> I understand that.  I was simply saying that your assertion that it  
> wouldn't clobber a file that lacked the "auto-generated" line was not  
> the current reality.  It was unclear to me from that message whether  
> you were discussing actual behavior or ideal behavior, so I tested it  
> myself.  Sorry, I should have put a smiley after my SVN comment.  :-D

	Heh. This is all proposed behaviour. Everybody seems to agree the
current behaviour isn't ideal, so before I write a patch (looks like John
Peacock might have beat me too it anyway) I just wanted to be clear on the
solution. Bitching about an existing Makefile.PL seems to be the lowest
common denominator among all the ideas that have gone back and forth, so
that should definately be implemented first. What's still in the air;

	- Whether or not we check for the "auto-generated by MB::Compat"
line

	- Whether or not we add an explicit 'skip' argument to
create_makefile_pl, which follows through to;

	- Whether or not we complain and/or fail to function if the module
developer has not specified "create_makefile_pl" at all.

	Cheers,
		Tyler

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

On Feb 14, 2006, at 3:18 PM, John Peacock wrote:

> Tyler MacDonald wrote:
>> 	Seriously though, it sounds like having at least a loud warning "I
>> did not write this Makefile.PL, move it out of the way first" is  
>> worthwhile.
>
> Pseudocode:
>
> if ($mb->overwrite_makefile() && -f $Makefile ) {
>     my $answer = $mb->y_n("Found an existing Makefile.PL;  
> overwrite?");
>     if ($answer =~/y/i) {
>         write_makefile;
>     }
> }
>
> where overwrite_makefile is a package option passed to M::B::new 
> ().  I did it this way so that
>
> a) the developer has to affirmatively choose that option;
> b) the developer has to _always_ hit 'Y' when running './Build  
> distdir', just in case he/she did something manually and forgot to  
> turn off the option.

Ugh, I have to hit "Y" every time???  If you add the following to the  
conditional, I'd be happy:
   && slurp($Makefile) !~ /auto.generated/is

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] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

John Peacock <jpe...@ro...> wrote:
> if ($mb->overwrite_makefile() && -f $Makefile ) {
>     my $answer = $mb->y_n("Found an existing Makefile.PL; overwrite?");
>     if ($answer =~/y/i) {
>         write_makefile;
>     }
> }
> 
> where overwrite_makefile is a package option passed to M::B::new().  I 
> did it this way so that
> 
> a) the developer has to affirmatively choose that option;
> b) the developer has to _always_ hit 'Y' when running './Build distdir', 
> just in case he/she did something manually and forgot to turn off the 
> option.

	So that's in there now?

	BTW.. tsk tsk... y_n requires a default now. ;-)

		- Tyler

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

On Feb 14, 2006, at 3:06 PM, Tyler MacDonald wrote:

> Chris Dolan <ch...@cl...> wrote:
>>> 	Well it would only clobber the file if it contained the
>>> "auto-generated" line, so I think that's safe, but if you want to be
>>> *really* paranoid, how about having the dist actions fail if you  
>>> havent
>>> specified a "create_makfile_pl" arg? (one of the exsitng ones or  
>>> "skip").
>> I just tested and CVS HEAD M::B happily overwrote a hand-made
>> Makefile.PL when I added 'traditional' to Build.PL and ran "Build
>> distdir".  Luckily, I had it in SVN so it was an easy restore.
>
> 	But that's exactly what you asked it to do. ;-)
>
> 	Seriously though, it sounds like having at least a loud warning "I
> did not write this Makefile.PL, move it out of the way first" is  
> worthwhile.
>
> 		- Tyler

I understand that.  I was simply saying that your assertion that it  
wouldn't clobber a file that lacked the "auto-generated" line was not  
the current reality.  It was unclear to me from that message whether  
you were discussing actual behavior or ideal behavior, so I tested it  
myself.  Sorry, I should have put a smiley after my SVN comment.  :-D

I like your proposed warning.

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] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

Tyler MacDonald wrote:
> 	Seriously though, it sounds like having at least a loud warning "I
> did not write this Makefile.PL, move it out of the way first" is worthwhile.

Pseudocode:

if ($mb->overwrite_makefile() && -f $Makefile ) {
     my $answer = $mb->y_n("Found an existing Makefile.PL; overwrite?");
     if ($answer =~/y/i) {
         write_makefile;
     }
}

where overwrite_makefile is a package option passed to M::B::new().  I 
did it this way so that

a) the developer has to affirmatively choose that option;
b) the developer has to _always_ hit 'Y' when running './Build distdir', 
just in case he/she did something manually and forgot to turn off the 
option.

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] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

Chris Dolan <ch...@cl...> wrote:
> >	Well it would only clobber the file if it contained the
> >"auto-generated" line, so I think that's safe, but if you want to be
> >*really* paranoid, how about having the dist actions fail if you havent
> >specified a "create_makfile_pl" arg? (one of the exsitng ones or "skip").
> I just tested and CVS HEAD M::B happily overwrote a hand-made  
> Makefile.PL when I added 'traditional' to Build.PL and ran "Build  
> distdir".  Luckily, I had it in SVN so it was an easy restore.

	But that's exactly what you asked it to do. ;-)

	Seriously though, it sounds like having at least a loud warning "I
did not write this Makefile.PL, move it out of the way first" is worthwhile.

		- Tyler

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

On Feb 14, 2006, at 2:40 PM, Tyler MacDonald wrote:

> 	Well it would only clobber the file if it contained the
> "auto-generated" line, so I think that's safe, but if you want to be
> *really* paranoid, how about having the dist actions fail if you  
> havent
> specified a "create_makfile_pl" arg? (one of the exsitng ones or  
> "skip").

I just tested and CVS HEAD M::B happily overwrote a hand-made  
Makefile.PL when I added 'traditional' to Build.PL and ran "Build  
distdir".  Luckily, I had it in SVN so it was an easy restore.

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] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

David Golden <da...@hy...> wrote:
> It's not so simple a change.  The Makefile.PL gets generated by 
> "distmeta", which "distdir" depends on.  "distmeta" also generates 
> README and META.yml.
> 
> I tend to run distmeta before checking in a release, so I have exactly 
> the Makefile.PL, README, and META.yml that get packaged up and uploaded 
> to CPAN.
> 
> I don't think anything that could clobber files should be switched on by 
> default.  That's just asking for trouble.

	Well it would only clobber the file if it contained the
"auto-generated" line, so I think that's safe, but if you want to be
*really* paranoid, how about having the dist actions fail if you havent
specified a "create_makfile_pl" arg? (one of the exsitng ones or "skip").

	That way CPAN etc would not be affected (since they don't run the
'dist' action), but module developers would be forced to specify the
create_makefile_pl action before they uploaded a new release.

	I see "maintaining both your own Build.PL and Makefile.PL" as a bit
of an edge case (not to mention a maintainer's nightmare), but there's gotta
be a way we can both support it and make the default Module::Build behaviour
friendly towards the CPAN.pm that's shipped with perl.

		- Tyler

[Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

Nick Ing-Simmons wrote:
> Chromatic <chr...@wg...> writes:
>> M::B provides the minimal features to get the module built, tested, and 
>> installed.  The bare tarball doesn't.  No slope.
> 
> I would like to switch to module build but AFAIK it still can't 
> do nested builds.

That discussion is happening on the Module-Build list even now.  The 
problem is that what "nested build" means is different for different 
people.  Personally, I'd like blib/lib and blib/arch to contain all sub 
blib's below the current one (strictly speaking a recursive build).  And 
at any level, a './Build command' will run all lower level ./Build files 
with the same command depth-first.

Is this what EUMM does now?  This seems to be what GNU automake/autoconf 
seems to expect.

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] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

Tyler MacDonald wrote:
> Ken Williams <ke...@ma...> wrote:
>> If we did that, we'd screw over people who are already maintaining 
>> their Makefile.PL separately by hand. 
> 
> 	OK... but if they are doing that, the Makefile.PL will be in their
> *build* directory already... as far as I understand, our Makefile.PL only
> needs to be generated in the *dist* directory.
> 
> 	The current behaviour is to not create a Makefile.PL during
> "./Build", only create it when "distdir" is run. However, the "distdir"
> action creates "Makefile.PL" in the current directory and then copies it
> over. 

It's not so simple a change.  The Makefile.PL gets generated by 
"distmeta", which "distdir" depends on.  "distmeta" also generates 
README and META.yml.

I tend to run distmeta before checking in a release, so I have exactly 
the Makefile.PL, README, and META.yml that get packaged up and uploaded 
to CPAN.

I don't think anything that could clobber files should be switched on by 
default.  That's just asking for trouble.

Regards,
David Golden

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

Ken Williams <ke...@ma...> wrote:
> If we did that, we'd screw over people who are already maintaining 
> their Makefile.PL separately by hand. 

	OK... but if they are doing that, the Makefile.PL will be in their
*build* directory already... as far as I understand, our Makefile.PL only
needs to be generated in the *dist* directory.

	The current behaviour is to not create a Makefile.PL during
"./Build", only create it when "distdir" is run. However, the "distdir"
action creates "Makefile.PL" in the current directory and then copies it
over. 

	The generated Makefile.PL's first line clearly says "auto-generated
by Module::Build::Compat"... soooo if somebody was maintaining a Makefile.PL
manually, we could easily auto-detect that by checking for the presence of
that line. Maybe echo a Big Fat Warning on the distdir action as well, if
they havent explicitly set "create_makefile_pl => skip".

	Do you think that would make everybody happy?

> Not everybody has as many  modules to maintain as we do, Tyler. =)

	Hah, you're way ahead of me on that one. ;) What scares me is how
many *nearly* complete modules i have sitting in my CVS tree that need just
a few more changes to be ready... each night I load up one and add a few
more methods/test cases/etc and think that's the night it's going to be
ready to release just to find a whole days' worth of work I hadn't
considered...

		- Tyler

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

Chris Dolan wrote:
> John, et al.
> 
> Please consider making that
>   cmp_ok $1, '==', $mb->VERSION, "Check version used to create META.yml: 
> $1 == " . $mb->VERSION;
> which makes for more readable failure cases.

Noted (and changed in my private branch).  Sorry, I was going for 
minimal change and not thinking about readability.

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: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

On Feb 14, 2006, at 12:37 PM, John Peacock wrote:

> ...
> -  is $1, $mb->VERSION, "Check version used to create META.yml: $1  
> == " . $mb->VERSION;
> +  ok $1 == $mb->VERSION, "Check version used to create META.yml:  
> $1 == " . $mb->VERSION;

John, et al.

Please consider making that
   cmp_ok $1, '==', $mb->VERSION, "Check version used to create  
META.yml: $1 == " . $mb->VERSION;
which makes for more readable failure cases.

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] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

On Feb 14, 2006, at 12:36 PM, Tyler MacDonald wrote:

> Could "create_makefile_pl => passthrough" Become
> the default, and a new option, "create_makefile_pl => skip" be created 
> to
> satisfy those who wish to screw over legacy users? :)

If we did that, we'd screw over people who are already maintaining 
their Makefile.PL separately by hand.  Not everybody has as many 
modules to maintain as we do, Tyler. =)

  -Ken

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

Ken Williams wrote:
> Randy just wrote me a message saying similar, so I think we should just 
> do the 0.28 release now.  We can make the version.pm and Build.bat 
> changes right away afterwards, or if we get some patches in the next day 
> or two I can put them in beforehand.

I've got a very simple patch (attached) to handle version.pm, but I have 
to delve deep to figure out why YAML is spewing warnings during 
t/runthrough.t in the

	$mb->dispatch('disttest');

code on line 120.  I'm sure I can figure that out tonight if I had to.

I was also going to suggesting moving the version range code for 
PREREQUISITES get encapsulated in the new Module::Build::version object 
code, but that can wait til after 0.28 is out.

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] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

Ken Williams <ke...@ma...> wrote:
> I agree on the personal rights aspect here. =)  I'd still recommend 
> that people include a Makefile.PL, but we can't force it.  That would 
> just mean people would have to find creative method to break the 
> enforcement if they really know what they're doing.

	With that in mind, I decided to see what happens with the most
minimal build.PL possible. It ends up being this:

use Module::Build;
Module::Build->new(
 'dist_name','foo',
 'dist_version',0.01,
 'dist_author','me',
 'dist_abstract','you bet'
)->create_build_script;

faraway@pipewrench:~/dev/foo$ perl Build.PL
Checking prerequisites...
Looks good

Creating new 'Build' script for 'foo' version '0.01'
faraway@pipewrench:~/dev/foo$ ./Build distdir
No license specified, setting license = 'unknown'
Deleting META.yml
Creating META.yml
WARNING: Possible missing or corrupt 'MANIFEST' file.
Nothing to enter for 'provides' field in META.yml
Can't create distdir without a MANIFEST file - run 'manifest' action first
at /usr/local/share/perl/5.8.7/Module/Build/Base.pm line 2754.
faraway@pipewrench:~/dev/foo$ ./Build manifest
File 'MANIFEST.SKIP' does not exist: Creating a default 'MANIFEST.SKIP'
Added to MANIFEST: Build.PL
Added to MANIFEST: MANIFEST
Added to MANIFEST: META.yml
faraway@pipewrench:~/dev/foo$ ./Build distdir
No license specified, setting license = 'unknown'
Deleting META.yml
Creating META.yml
Creating foo-0.01
faraway@pipewrench:~/dev/foo$ ls foo-0.01/
Build.PL  MANIFEST  META.yml
faraway@pipewrench:~/dev/foo$

	No Makefile.PL. :-( Could "create_makefile_pl => passthrough" Become
the default, and a new option, "create_makefile_pl => skip" be created to
satisfy those who wish to screw over legacy users? :)

		- Tyler

Re: 0.28 release date? (was Re: [Module::Build] Recursive builds?)

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

On Feb 14, 2006, at 8:46 AM, Rob Kinyon wrote:

> On 2/13/06, Ken Williams <ke...@ma...> wrote:
>> nice solid way would be a major project.  We're scheduling it for the
>> next big release, i.e. after 0.27_xx becomes 0.28xx.
>
> Is there a current plan for the 0.28 release? There are a number of
> features that I would love to use, but I can't until 0.28 is released
> ...

The only thing we're waiting for is to fix the CPANPLUS bug in which 
installation error output doesn't get included in cpan-testers reports. 
  I'm not sure that's really going to happen right away though, because 
I can't get my tuits together for it.

Randy just wrote me a message saying similar, so I think we should just 
do the 0.28 release now.  We can make the version.pm and Build.bat 
changes right away afterwards, or if we get some patches in the next 
day or two I can put them in beforehand.

  -Ken

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

On Feb 14, 2006, at 12:10 PM, John Peacock wrote:

> I would certainly accept a mandatory warning during './Build dist' if 
> there was no Makefile.PL present, but I think that assuming that 
> everyone wants to release to CPAN is grossly inappropriate.

Yes, I was going to make that point too but I forgot.  CPAN isn't the 
whole world.


> I personally have released modules to CPAN lacking a Makefile.PL, but 
> mostly because I forgot to add one (and since I now try to use 
> Module::Starter::PBP, that isn't going to happen again).  I strongly 
> support any author who wants to include only a Build.PL because they 
> don't care if people who refuse to upgrade their core modules get 
> burned. ;-)

I agree on the personal rights aspect here. =)  I'd still recommend 
that people include a Makefile.PL, but we can't force it.  That would 
just mean people would have to find creative method to break the 
enforcement if they really know what they're doing.

  -Ken

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

On Feb 14, 2006, at 11:16 AM, demerphq wrote:

> My understanding of this (and i hope im not putting words in Adams
> mouth) is that anybody using an old CPAN can't install a distribution
> that requires Module::Build unless a Makefile.PL is present.

Right.

> Since this is a big chunk of the cpan's out there it affects a lot of 
> users,
> and in my experience is one of the reasons that people often get a bad
> impression of MB on their first exposure as there is a good chance
> that the first time they notice something uses MB will be when CPAN
> fails to install because of the missing Makefile.pl

Agreed.

> IOW, no dist should ever be released to CPAN without a Makefile.PL and
> MB should not allow anyone to create such a dist.

I personally agree, but I'd rather implement it as a sanity check 
rather than a forced decision - something like, during the 'dist' 
action: "you're about to create a distribution that contains no 
Makefile.PL.  This will limit the ability of CPAN users to install your 
module.  Are you sure you want to continue?"

If they answer no (or heck, even if they answer yes), we can point them 
to the documentation for Module::Build::Compat so they can 
auto-generate an appropriate Makefile.PL.

  -Ken

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker in 5.8.8 for UINST=1

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

demerphq wrote:
> My understanding of this (and i hope im not putting words in Adams
> mouth) is that anybody using an old CPAN can't install a distribution
> that requires Module::Build unless a Makefile.PL is present. Since
> this is a big chunk of the cpan's out there it affects a lot of users,
> and in my experience is one of the reasons that people often get a bad
> impression of MB on their first exposure as there is a good chance
> that the first time they notice something uses MB will be when CPAN
> fails to install because of the missing Makefile.pl

Let's be clear about the scope of responsibilities here.  Every time you 
start an install using a backrev'd CPAN, you are given instructions for 
updating CPAN itself.  The current CPAN handles MB just fine, thanks, so 
the core problem is sysadmins who refuse to upgrade their basic tools. 
If this reflects badly on M::B it is due to sloth and inertia, and that 
isn't something that adding a Makefile.PL is going to automatically fix.

Of course, there is also the far superior CPANPLUS, which deals with 
M::B even better...

> IOW, no dist should ever be released to CPAN without a Makefile.PL and
> MB should not allow anyone to create such a dist. There is no need to
> make the Makefile.PL do any more than signal that MB needs to be
> installed and then hand over to it to do the dirty work. Such an
> implementation should work transparently on every CPAN ever released.

And who acts as gatekeeper?  PAUSE?  Module::Build itself???  This goes 
completely against the nature of CPAN, which is to accept all sorts of 
crap, with the good stuff eventually floating to the top (by being on a 
'use' line in every other module).

I would certainly accept a mandatory warning during './Build dist' if 
there was no Makefile.PL present, but I think that assuming that 
everyone wants to release to CPAN is grossly inappropriate.  I 
personally have released modules to CPAN lacking a Makefile.PL, but 
mostly because I forgot to add one (and since I now try to use 
Module::Starter::PBP, that isn't going to happen again).  I strongly 
support any author who wants to include only a Build.PL because they 
don't care if people who refuse to upgrade their core modules get 
burned. ;-)

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