headers
Ken Williams | 13 Sep 2003 17:25
Favicon

Re: [idea] readme_from => $file


On Friday, September 12, 2003, at 09:06  PM, Michael G Schwern wrote:

> On Fri, Sep 12, 2003 at 02:48:35PM -0500, Ken Williams wrote:
>> You're reading my mind!  Earlier this week I committed a patch adding 
>> a
>> "create_readme" parameter, which uses the file in dist_version_from to
>> generate a README using pod2html.  Will you need more flexibility than
>> that?
>
> pod2html?  By all that is 7bit ASCII I hope you meant Pod::Text.

Oh, indeed - it's Pod::Text.

  -Ken

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Ed Avis | 13 Sep 2003 10:29
Favicon

Module::Build and Module::Install

What is the connection between Module::Build and Module::Install?  
The documentation
<http://search.cpan.org/author/KWILLIAMS/Module-Build-0.20_01/lib/Module/Build.pm>
says:

>If you want the installation process to look around in  <at> INC for other
>versions of the stuff you're installing and try to delete it, you can
>use the uninst parameter, which tells Module::Install to do so:

but doesn't mention that module anywhere else.

--

-- 
Ed Avis <ed <at> membled.com>

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 501 comments |
headers
Ken Williams | 13 Sep 2003 17:30
Favicon

Re: Module::Build and Module::Install


On Saturday, September 13, 2003, at 03:29  AM, Ed Avis wrote:

> What is the connection between Module::Build and Module::Install?
> The documentation
> <http://search.cpan.org/author/KWILLIAMS/Module-Build-0.20_01/lib/ 
> Module/Build.pm>
> says:
>
>> If you want the installation process to look around in  <at> INC for other
>> versions of the stuff you're installing and try to delete it, you can
>> use the uninst parameter, which tells Module::Install to do so:
>
> but doesn't mention that module anywhere else.
>

Oops, sorry, that's an error - it should have said ExtUtils::Install.   
I'll fix it.

Module::Build currently knows nothing about Module::Install.  I think  
Module::Install may know something about Module::Build, but I'm not  
sure.

  -Ken

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
(Continue reading)

Permalink | Reply | 501 comments |
headers
Mark Stosberg | 15 Sep 2003 03:57
Picon
Favicon
Gravatar

A portable README generation syntax?

Hello,

I've noticed that a number of Perl modules have a README file that
repeats the contents of the primary modules documentation in a text
based format. This seems reasonable to me. 

[ Puts on thinking cap for a moment. ]. A bit of reflection generated a
couple important thoughts about this:

1. Portability doesn't matter for users in this case, just other
developers who do "Make dist".

2. Here's a syntax that should be portable, using Pod::Text:

	use Module::Build;

	my $class = Module::Build->subclass(
			class => 'CGI::Session::PureSQL::Builder',
			code => q{
			sub ACTION_dist {
			my $self = shift;
			use Pod::Text;
			my $parser = Pod::Text->new;
			$parser->parse_from_file('./lib/CGI/Session/PureSQL.pm', 'README');
			$self->SUPER::ACTION_dist;
			}
			},
			);

	$class->new(
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Williams | 15 Sep 2003 17:29
Favicon

Re: A portable README generation syntax?

On Sunday, September 14, 2003, at 08:57  PM, Mark Stosberg wrote:
>
> I've noticed that a number of Perl modules have a README file that
> repeats the contents of the primary modules documentation in a text
> based format. This seems reasonable to me.

[...]

> If this seems like a common and useful thing that people would want to 
> do with
> Module::Build, perhaps it could warrant syntax shortcut.

Hi Mark,

This has already been added to the CVS version of Module::Build, with a 
simple 'create_readme' parameter passed to the new() method.

  -Ken

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Steve Purkis | 15 Sep 2003 18:03

[BUG] ./Build dist does not check for new $VERSION

Hi all,

When you update the 'dist_version_from' file *after* running Build.PL, 
the 'dist' action builds a tarball for the old version (which seems 
wrong to me).  Perhaps it should check for a new $VERSION and rebuild 
the cache if it has changed?

-Steve

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 2 comments |
headers
Ken Williams | 15 Sep 2003 19:15
Favicon

Re: [BUG] ./Build dist does not check for new $VERSION


On Monday, September 15, 2003, at 11:03  AM, Steve Purkis wrote:

> Hi all,
>
> When you update the 'dist_version_from' file *after* running Build.PL, 
> the 'dist' action builds a tarball for the old version (which seems 
> wrong to me).  Perhaps it should check for a new $VERSION and rebuild 
> the cache if it has changed?
>

Yeah, this is known behavior (though perhaps not to anyone but me?).  
The Build.PL step solidifies various configuration information, then 
the subsequent steps do everything based on this configuration.

I think you're probably right about the solution, though I think maybe 
the user should have to manually do the update after we give a warning. 
  Otherwise we may end up losing any parameters the user specified to 
the Build.PL invocation.

Or we could just change the version number itself, and nothing else, in 
the cache.  Which makes me think maybe we shouldn't cache it there at 
all...

  -Ken

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steve Purkis | 15 Sep 2003 20:01

Re: [BUG] ./Build dist does not check for new $VERSION

On Monday, September 15, 2003, at 06:15  pm, Ken Williams wrote:

> On Monday, September 15, 2003, at 11:03  AM, Steve Purkis wrote:
>
>> Hi all,
>>
>> When you update the 'dist_version_from' file *after* running 
>> Build.PL, the 'dist' action builds a tarball for the old version 
>> (which seems wrong to me).  Perhaps it should check for a new 
>> $VERSION and rebuild the cache if it has changed?
>>
>
> Yeah, this is known behavior (though perhaps not to anyone but me?).  
> The Build.PL step solidifies various configuration information, then 
> the subsequent steps do everything based on this configuration.

I've noticed that - for example if a Build.PL ever changes, running 
./Build <whatever> doesn't trigger a rebuild of the Build script like 
MakeMaker's Makefiles did.

> I think you're probably right about the solution, though I think maybe 
> the user should have to manually do the update after we give a 
> warning.  Otherwise we may end up losing any parameters the user 
> specified to the Build.PL invocation.
>
> Or we could just change the version number itself, and nothing else, 
> in the cache.  Which makes me think maybe we shouldn't cache it there 
> at all...

I prefer the warning option, mainly because a general solution to it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Williams | 16 Sep 2003 20:57
Favicon

Re: build_recommends argument for new()?

Hi Dennis,

You're quite right, the dimensions of "recommended vs. required vs. 
conflicts" and "build vs. test" should really be independent.

The next major issue for us to sort out in M::B is that of 
dependencies.  I've just added an item to the TODO file for it.  I'm a 
little hesitant to add much support for build_recommends before the 
larger issues are resolved.

It might be good enough for you to just not mention Struct::Compare in 
your prerequisites for now, and just use it if it's present?

  -Ken

On Wednesday, September 10, 2003, at 02:20  PM, Dennis Sutch wrote:

> Would it be possible to include a build_recommends argument for the 
> new()
> method?
>
> I have a module which optionally uses the module Struct::Compare in 
> build
> tests, if that module is found.  This module really shouldn't be
> designated as "build_requires", since it is not necessary for the 
> build.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin J. Tilly | 18 Sep 2003 21:42

Fw: Re: Module::Build::Compat should not recommend not having a Makefile.PL

I am forwarding this message as requested by Ken.  I am not on the
Module::Build list, so please keep me in the CC list.

My perspective is that CPAN authors should make at least a token nod
towards attempting to be compatible with existing installations.  For
the forseeable future a significant fraction of the installed Perl
base will be using versions of Perl and CPAN which will break if
Makefile.PL is not present.  Attempting to force them to change that
decision (which may be made for many reasons, and at many sites is
NOT a programmer-level decision) will create a certain level of
knee-jerk resentment and ill-will.  I see no good reason to encourage
this kind of problem.  My opinion is that attempts to shove a better
way down people's throats is a good way to feel like you really tried
while accomplishing negative work.

Speaking personally, when there is an accepted standard way of doing
things, I tend to look with extreme suspicion on anyone who tells me
that I need to do things their own, newfangled way.  It would not be
inaccurate to read that as, "I reject them out of hand until someone I
trust tells me to reconsider."  I believe that this approach is fairly
common.  And it is what I did when I heard about Module::Build.

But now that I have reconsidered it, I can see benefits of using
Module::Build.  I intend to update my handful of modules to use it as a
convenience to potential Windows users.  However I see no reason to
penalize people who aren't playing with the latest shiny toys, and so
will use the backwards compatibility tool.  And I would encourage
others to do the same.

In short, encouraging people to use Module::Build and
(Continue reading)

Permalink | Reply | 0 comments |

Gmane