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

Re: [Module::Build] SF.net is not long for this M::B world

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

Ken,

Can you give us a target timeframe for when 0.28 might go out?
Is there a feature freeze period before that?

I have some things I might hope to have considered before
the next major release.

Stephen

On 3/23/06, Ken Williams <ke...@ma...> wrote:
> So finally I get some time to look at a few M::B issues, and CVS
> seems to be down.  I see this note on the sourceforge status page:
>
>   ( 2006-03-23 10:28:40 - Project CVS Service )   2006-03-23:
> Starting at 19:00 PST, CVS services will be unavailable for
> approximately 8 hours as part of routine maintenance. We apologise
> for the inconvenience.
>
> Of course, up above on the same page, CVS status is listed as "Online".
>
> I'm tired of both CVS itself and these outages, so other than just
> complaining publicly, I'm announcing that we'll switch to subversion
> once we generate the 0.28 release, and perhaps try to move to the
> svn.perl.org server too.  I don't know if it's more reliable or not,
> but for some reason I'm sure it would be less frustrating.
>
>   -Ken
>
>
>
> -------------------------------------------------------
> 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
>

[Module::Build] SF.net is not long for this M::B world

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

So finally I get some time to look at a few M::B issues, and CVS  
seems to be down.  I see this note on the sourceforge status page:

  ( 2006-03-23 10:28:40 - Project CVS Service )   2006-03-23:  
Starting at 19:00 PST, CVS services will be unavailable for  
approximately 8 hours as part of routine maintenance. We apologise  
for the inconvenience.

Of course, up above on the same page, CVS status is listed as "Online".

I'm tired of both CVS itself and these outages, so other than just  
complaining publicly, I'm announcing that we'll switch to subversion  
once we generate the 0.28 release, and perhaps try to move to the  
svn.perl.org server too.  I don't know if it's more reliable or not,  
but for some reason I'm sure it would be less frustrating.

  -Ken

[Module::Build] Cannot forceunlink C:\Perl\site\lib\auto\Compress\Zlib\Zlib.dll: Permission denied at C:/Perl/lib/File/Find.pm line 906

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

Hi Folks

I've been investigating this problem.

I get such an error with Compress::Zlib, Params::Validate and Time::HiRes.

Here's what I've found, under Win2K:

o If Apache+mod_perl is not installed (i.e. as a Windows service), I do not=
 get 
this error.

o If Apache+mod_perl is installed but the service is not started, I do not=
 get 
this error

o If the service is started, I get this error

What complicates the issue is that Apache, or perhaps Windows, is=
 inconsistent 
about whether or not it is installed. Here's a log of a few attempts to play=
 
with this:

-----><8-----
<Firstly, I stop the Apache service via the control panel. Then...>

C:\perl-modules>apache -k uninstall
Removing the Apache2 service
The Apache2 service has been removed successfully.

<Snip installing Compress::Zlib. This is the only snippage in this log>

C:\perl-modules>apache -k install
[Fri Mar 24 08:52:14 2006] [error] Apache2: Service is already installed.

C:\perl-modules>apache -k uninstall
Removing the Apache2 service
(OS 1072)The specified service has been marked for deletion.  : Apache2:=
 Failed 
to delete the servic
e.

C:\perl-modules>apache -k install
[Fri Mar 24 08:52:27 2006] [error] Apache2: Service is already installed.

C:\perl-modules>
C:\perl-modules>
C:\perl-modules>
C:\perl-modules>apache -k install

C:\perl-modules>apache -k uninstall
Removing the Apache2 service
The Apache2 service has been removed successfully.

C:\perl-modules>apache -k install

C:\perl-modules>apache -k uninstall
Removing the Apache2 service
The Apache2 service has been removed successfully.

C:\perl-modules>apache -k install

C:\perl-modules>
-----><8-----

HTH
-- 
Cheers
Ron Savage, ro...@sa... on 24/03/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

[Module::Build] Data::Package::*, File::ShareDir and the 'auto/' subdir

[Steffen S. <sch...@we...>]

Hi!

Once upon a time, I already asked a similar question, where to install
non-perl files. I then solved it by installing files with an own
suffix into @INC near the module.

This time I want to install rather large amounts of data.

I could install them again beside the module, but in the mean time I
read about a "more official" sounding way in the documentation of the
modules

  Data::Package (::SQLite)
  File::ShareDir
  Module::Install::Share

which would all solve this problem by installing data in the 'data/'
subdir near the module and finding them there at runtime.

By looking into the source, it seems, Module::Install:Share simply
uses a MakeMaker variable INST_AUTODIR (which itself is just a
relative subdir to INST_LIBDIR).

I want to use this way (i.e., Data::Package::SQLite with data files in
'auto/'), but install them with Module::Build.

==> The question:

    How can I detect the 'auto/' subdir at install time and define
    rules in Build.PL that install, for instance, all files from a
    'share/' subdir into the corresponding 'auto/' subdir?


(Greeti+Tha)nX
Steffen
-- 
Steffen Schwigon <sch...@we...>
Dresden Perl Mongers <http://dresden-pm.org/>

Re: [Module::Build] [PATCH] update bundled Tie::CPHash

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

On Mar 21, 2006, at 1:51 AM, Yitzchak Scott-Thoennes wrote:

> Update to a newer version of Tie::CPHash which includes support for
> the 5.8.3+ SCALAR method.  This isn't needed for MB's purposes, but
> the bundled version really should stay current.  I doubt there will be
> any further changes for a long time to come.


Thanks, applied.

  -Ken

[Module::Build] [PATCH] update bundled Tie::CPHash

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

Update to a newer version of Tie::CPHash which includes support for
the 5.8.3+ SCALAR method.  This isn't needed for MB's purposes, but
the bundled version really should stay current.  I doubt there will be
any further changes for a long time to come.

--- Module-Build/t/bundled/Tie/CPHash.pm.orig	2006-02-25 07:27:27.000000000 -0800
+++ Module-Build/t/bundled/Tie/CPHash.pm	2006-03-12 18:12:22.000000000 -0800
@@ -3,9 +3,9 @@
 #
 # Copyright 1997 Christopher J. Madsen
 #
-# Author: Christopher J. Madsen <chr...@ge...>
+# Author: Christopher J. Madsen <cj...@po...>
 # Created: 08 Nov 1997
-# Version: 1.001 (25-Oct-1998)
+# $Revision: 1268 $  $Date: 2006-03-12 20:12:22 -0600 (Sun, 12 Mar 2006) $
 #
 # This program is free software; you can redistribute it and/or modify
 # it under the same terms as Perl itself.
@@ -27,11 +27,7 @@
 #=====================================================================
 # Package Global Variables:
 
-BEGIN
-{
-    # Convert RCS revision number to d.ddd format:
-    $VERSION = sprintf('%d.%03d', '1.001 ' =~ /(\d+)\.(\d+)/);
-} # end BEGIN
+$VERSION = '1.02';
 
 #=====================================================================
 # Tied Methods:
@@ -85,6 +81,15 @@
 } # end NEXTKEY
 
 #---------------------------------------------------------------------
+# SCALAR this
+#     Return bucket usage information for the hash (0 if empty).
+
+sub SCALAR
+{
+    scalar %{$_[0]};
+} # end SCALAR
+
+#---------------------------------------------------------------------
 # EXISTS this, key
 #     Verify that *key* exists with the tied hash *this*.
 
@@ -147,8 +152,8 @@
 
 =head1 DESCRIPTION
 
-The B<Tie::CPHash> provides a hash table that is case preserving but
-case insensitive.  This means that
+The B<Tie::CPHash> module provides a hash table that is case
+preserving but case insensitive.  This means that
 
     $cphash{KEY}    $cphash{key}
     $cphash{Key}    $cphash{keY}
@@ -180,7 +185,7 @@
 
 =head1 AUTHOR
 
-Christopher J. Madsen E<lt>F<chr...@ge...>E<gt>
+Christopher J. Madsen E<lt>F<cj...@po...>E<gt>
 
 =cut
 

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

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

On Mar 20, 2006, at 10:21 PM, Stephen Adkins wrote:

> On 3/20/06, John Peacock <jpe...@ro...> wrote:
>> Stephen Adkins wrote:
>>> I have modified a version of Module::Build::Base from Module- 
>>> Build-0.2611
>>> to add YAML support sufficient to do everything that  
>>> Module::Build needs.
>>
>> Excellent!
>>
>
> OK.
> I have completed the patch for Module::Build::YAML and have  
> attached the
> patch files rather than inlining them in this message.
> I created two new files and have attached them also.

Looks great, I've committed the patch.

I'm thinking we might even want to get rid of our reliance on YAML.pm  
entirely and use this even when the user *does* have YAML installed.   
That dependency has been like a monkey around our neck.  Or something.

> P.S. Please give me feedback on this patch.
> I hope to make other contributions in the future, and I hope I'm  
> doing it right.

Yup, this is great.  One thing that can make it so you don't have to  
use multiple attachments is the -N flag to diff, which treats absent  
files as if they're present but empty.  patch will then create the  
new files.

  -Ken

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

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

On Mar 20, 2006, at 10:09 PM, 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?
>

Possible, but I think we should get the first version of it with just  
the bare-bones writing capabilities.  CPAN.pm also needs reading, and  
might therefore need the full capabilities of YAML.pm if someone puts  
whatever obscure YAML syntax into their YETI.mammal file.

  -Ken

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

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

On 3/20/06, John Peacock <jpe...@ro...> wrote:
> Stephen Adkins wrote:
> > I have modified a version of Module::Build::Base from Module-Build-0.26=
11
> > to add YAML support sufficient to do everything that Module::Build need=
s.
>
> Excellent!
>

OK.
I have completed the patch for Module::Build::YAML and have attached the
patch files rather than inlining them in this message.
I created two new files and have attached them also.
I do not have write access to the CVS repository so I could not "cvs add" t=
hem
and include them in the patch/diff file.

FILES AFFECTED BY "yaml.diff" (the diff/patch file)
MANIFEST - added lib/Module/Build/YAML.pm, t/mbyaml.t
lib/Module/Build.pm - change doc to reflect YAML capabilities
lib/Module/Build/Base.pm - invoke Module::Build::YAML properly
t/metadata.t - remove tests of _yaml_quote_string()

NEW FILES
lib/Module/Build/YAML.pm - new module. works like YAML.pm for limited cases
t/mbyaml.t - new test script

NOTE: This patch is against the HEAD, not the 0.2611 branch.

Stephen Adkins

P.S. Please give me feedback on this patch.
I hope to make other contributions in the future, and I hope I'm doing it r=
ight.

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

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

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?

Regards,
David Golden

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

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

On Mar 20, 2006, at 8:14 AM, 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).

An excellent idea, it will be nice to have it in its own .pm for ease  
of testing, better interface, etc.

  -Ken

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

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

On Mar 20, 2006, at 12:18 PM, Andy Dougherty wrote:

> On Mon, 20 Mar 2006, Ken Williams wrote:
>
>>
>> On Mar 20, 2006, at 5:23 AM, Randy W. Sims wrote:
>>>
>>> The update to EU::CBuilder provided only part of the fix. We do  
>>> have a fix
>>> in cvs for the other failures related to Module::Build on BSD.  
>>> There are a
>>> couple of other things that I need to fix: some warnings from  
>>> Archive::Tar,
>>> failures on Windows when using Borland compiler, and I also need  
>>> to check
>>> MinGW on Windows...
>>
>>
>> We probably shouldn't worry too much about Archive::Tar just yet,  
>> it's
>> producing a few failures of its own in blead on OS X, so it's  
>> probably a
>> moving target.
>
> As of today, I'm still getting a number of failures, all of the form
>
> ../lib/Module/Build/t/basic..................................Can't  
> locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4- 
> solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4- 
> solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .).
> BEGIN failed--compilation aborted.
> Use of uninitialized value $perl in concatenation (.) or string at / 
> home/doughera/src/perl/perl-andy/t/../lib/Module/Build/Base.pm line  
> 1162.
> sh: -le: not found
> ok
>
> What's perhaps equally distressing is that despite these failures,
> t/harness still reports "All tests successful":
>

It's actually telling the truth - all those "failures" are happening  
when it's poking around your disk looking for the right perl  
executable, and sometimes that produces a lot of noise.  It simply  
moves on and eventually finds the right one, and thus eventually  
succeeds.

We've got patches in the pipeline to help a lot with this, but  
they're not applied yet pending some fact-finding about them.

  -Ken

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

[Andy D. <dou...@la...>]

On Mon, 20 Mar 2006, Ken Williams wrote:

> 
> On Mar 20, 2006, at 5:23 AM, Randy W. Sims wrote:
> > 
> > The update to EU::CBuilder provided only part of the fix. We do have a fix
> > in cvs for the other failures related to Module::Build on BSD. There are a
> > couple of other things that I need to fix: some warnings from Archive::Tar,
> > failures on Windows when using Borland compiler, and I also need to check
> > MinGW on Windows...
> 
> 
> We probably shouldn't worry too much about Archive::Tar just yet, it's
> producing a few failures of its own in blead on OS X, so it's probably a
> moving target.

As of today, I'm still getting a number of failures, all of the form

../lib/Module/Build/t/basic..................................Can't locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4-solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4-solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .).
BEGIN failed--compilation aborted.
Use of uninitialized value $perl in concatenation (.) or string at /home/doughera/src/perl/perl-andy/t/../lib/Module/Build/Base.pm line 1162.
sh: -le: not found
ok

What's perhaps equally distressing is that despite these failures, 
t/harness still reports "All tests successful":

All tests successful (5 subtests UNEXPECTEDLY SUCCEEDED), 63 tests and 315 subtests skipped.
Files=1227, Tests=163911, 6437 wallclock secs (2076.56 cusr + 343.13 csys = 2419.69 CPU)

This also means that my previous report that Randy's patch worked may not 
have been entirely correct -- this failure may still have been present, 
but since it slips through the test harness, I might not have noticed it.

Lastly, here's a bit more verbosity on where it goes wrong.  
Specifically, only the tests where it runs ../../../perl Makefile.PL seem 
to fail. Again, the problem is @INC is looking for the not-yet-installed 
perl.

../lib/Module/Build/t/compat....1..60
ok 1
Warning: Removing existing directory '/home/doughera/src/perl/perl-andy/t/_tmp/Simple'
Checking whether your kit is complete...
Looks good

Checking prerequisites...
Looks good

Creating new 'Build' script for 'Simple' version '0.01'
ok 2
../../../perl Makefile.PL
# running Build.PL 
Can't locate Config.pm in @INC (@INC contains: /tmp/perl/lib/5.9.4/sun4-solaris /tmp/perl/lib/5.9.4 /tmp/perl/lib/site_perl/5.9.4/sun4-solaris /tmp/perl/lib/site_perl/5.9.4 /tmp/perl/lib/site_perl .).
BEGIN failed--compilation aborted.
sh: -le: not found
./../../../perl Build.PL
Checking whether your kit is complete...
Looks good

Checking prerequisites...
Looks good

Deleting Build
Removed previous script 'Build'

Creating new 'Build' script for 'Simple' version '0.01'
ok 3


-- 
    Andy Dougherty		dou...@la...

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

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

Stephen Adkins wrote:
> I have modified a version of Module::Build::Base from Module-Build-0.2611
> to add YAML support sufficient to do everything that Module::Build needs.

Excellent!

> 
> In essence, I have replaced write_minimal_metadata() with write_metadata().
> This new write_metadata() method does everything that is needed to
> write META.yml
> but it does it without YAML.pm.  Thus, we could remove all dependency on YAML.pm
> completely. (Or, we merely use the internal routine if the external YAML.pm does
> not exist.)

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).

> 
>  1. How exactly should I submit this? 

Check out a new working copy from CVS, then copy your changes in place 
and then run, e.g.

	$ cvs diff -u > yaml.diff

If you do as I suggested above and separate the code into a new module, 
you will need to do a

	$ cvs add lib/Module/Build/YAML.pm

before the above, so that you get the new file added too.

HTH

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] Re: Module::Build 0.27_09 -> CPAN

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

On Mar 20, 2006, at 5:23 AM, Randy W. Sims wrote:
>
> The update to EU::CBuilder provided only part of the fix. We do  
> have a fix in cvs for the other failures related to Module::Build  
> on BSD. There are a couple of other things that I need to fix: some  
> warnings from Archive::Tar, failures on Windows when using Borland  
> compiler, and I also need to check MinGW on Windows...


We probably shouldn't worry too much about Archive::Tar just yet,  
it's producing a few failures of its own in blead on OS X, so it's  
probably a moving target.

  -Ken

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

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

Dominic Dunlop wrote:
> On 2006–03–14, at 03:02, Randy W. Sims wrote:
> 
>> Attached is a working (not final) patch that works for me on  FreeBSD, 
>> Ubuntu Linux, Windows XP, and cygwin. Could you please  give it a spin?
> 
> 
> How's this getting along? Even though change 27531, Upgrade to  
> ExtUtils::CBuilder 0.17, cuts the number of failures on Mac OS X from  
> seven to two, testing still produces a vast number of warnings -- see  
> the attached file.
> 
> The provisional patch you posted in the mail I'm replying to had a  
> better effect, making all tests pass and suppressing all warnings.

The update to EU::CBuilder provided only part of the fix. We do have a 
fix in cvs for the other failures related to Module::Build on BSD. There 
are a couple of other things that I need to fix: some warnings from 
Archive::Tar, failures on Windows when using Borland compiler, and I 
also need to check MinGW on Windows...

Randy.

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

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

> > If people thought this was a good idea (and the solution to some of the=
se
> > problems), I would be happy to write it.
...
> That would be awesome.
...
>   -Ken

Hi,

Ken said this would be useful, so I am ready to submit a patch.

I have modified a version of Module::Build::Base from Module-Build-0.2611
to add YAML support sufficient to do everything that Module::Build needs.

In essence, I have replaced write_minimal_metadata() with write_metadata().
This new write_metadata() method does everything that is needed to
write META.yml
but it does it without YAML.pm.  Thus, we could remove all dependency on YA=
ML.pm
completely. (Or, we merely use the internal routine if the external YAML.pm=
 does
not exist.)

 1. How exactly should I submit this? (I am not experienced with
submitting patches
     in the "right form".)  Should I check out from anonymous CVS? Do some =
diff
     command?  Can someone tell me the exact sequence of commands to get th=
e
     right style of diff after I check out from CVS? Or do I just send
in my version
     of Module::Build::Base?
 2. I could also make the modification to the CVS HEAD. Do you want me
to do that?
 3. Should we get rid of any dependence upon YAML.pm altogether?
     We could use the internal routine exclusively.  Or should we use
YAML.pm if it
     exists and use the internal routine if it does not exist?

Please let me know.

Stephen

On 2/26/06, Ken Williams <ke...@ma...> wrote:
>
> On Feb 19, 2006, at 3:51 PM, Stephen Adkins wrote:
>
> > It has already been stated that the subset of the YAML
> > specification actually
> > needed by Module::Build is quite limited.
> >
> > Why not write a module (Module::Build::YAML) which is included in
> > the M::B
> > distribution which supplies all of the YAML functionality required
> > by M::B.
> > Then there would never again be a system which had M::B but did not
> > have
> > enough YAML support in order to support its functions?
>
> Yes, I've been coming to the same conclusion.  I think it's probably
> the right way to go in this situation - we only write YAML, never
> read it, and the subset of things we need to know how to write is
> pretty simple.
>
> Witness the existing _yaml_quote_string() method, which is darn close
> to doing everything we need for YAML-writing (though I'm not quite
> sure it's totally correct).
>
> > If people thought this was a good idea (and the solution to some of
> > these
> > problems), I would be happy to write it. (But it's not so hard, and
> > I imagine
> > others could write it too and not have to wait for me.)
>
> That would be awesome.
>
> I think the set of types we need to write in YAML are:
>
>   * Strings
>   * Booleans
>   * Arrays whose entries are members of this set
>   * Hashes whose entries are members of this set
>
> and no reference loops.  So to do arrays, for example, you can just
> recurse on the elements of the array.
>
>   -Ken
>
>

[Module::Build] New version of ex-ExtUtils-Install released.

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

Ive released a new version of the ex-ExtUtils-Install bundle. It has
support for an INSTALL.SKIP file or MANIFEST.SKIP file being used to
prevent the installation of cruft like .bak files or .svn directories
or whatever.

Yves


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

Re: [Module::Build] Asking the unaskable

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

Johan Vromans wrote:
>> I'm unfortunately not very well-versed in Module::Install, so I
>> probably can't comment too much about it.
> 
> As for many modules, there's very little (mostly: nothing) that needs
> to be built. It's just a matter of dropping the modules in the right
> place. For purposes like this, a simple installer (as opposed to a
> builder) would suffice. AFAIK, M::I tries to be just that: an
> installer. And, as already noticed, it includes its code in the kit so
> it doesn't need any modules pre-installed.

Here's an example of the problems with Module::Install in its current 
state:  I recently tried manually upgrading HTTP::Server::Simple to 0.18 
after upgrading to Win32 ActiveState 5.8.8 (which supposedly supports 
cpan out of the box).  However, H::S::S has M::I version 0.52, which 
uses an @INC hack which is incompatible with the way Config.pm is 
modified by AS5.8.8.  The latest M::I is version 0.61, which fixes that bug.

My interim fix, based on advice from Jesse, was to install M::I 0.61, 
delete the inc/ directory, and then run Makefile.PL, which recreates inc 
using 0.61 and then installs fine.

The "proper" fix is to wait until Jesse releases H::S::S 0.19, which 
bundles M::I 0.61 (or better).

So, at least in its current alpha/beta state, using M::I means that 
you've hooked yourself on to that dependency chain.  I currently 
maintain about 17 CPAN distributions.  If I used M::I for all of them, 
then whenever a bug is found in M::I, or whenever something else changes 
that breaks something in M::I, I would need to bump versions, repackage 
and re-release all 17 distributions to ensure that everyone will be 
successful installing my module.

Yes, that can be automated, but it's still a big philosophy difference. 
  And I cringe thinking about the scenario where hundreds of 
distributions all version bump and resubmit to PAUSE every time that 
M::I changes versions to fix a bug for some platform.

Regards,
David

Re: [Module::Build] Asking the unaskable

[Johan V. <jvr...@sq...>]

Ken Williams <ke...@ma...> writes:

> You realize you've walked into a lion's den and asked whether meat
> or eggplant tastes better, right? =)

:-)

> One concrete area where M::B has an advantage is its ability to add
> custom installable components to the mix.  That's tough to do in a
> flexible way with MakeMaker.

My main concern is whether it is sufficiently complete for 'real use'.
But I must say that my Makefile.PL's are ususally quite
straightforward and M::B had improved much since the last time I
looked.

> I'm unfortunately not very well-versed in Module::Install, so I
> probably can't comment too much about it.

As for many modules, there's very little (mostly: nothing) that needs
to be built. It's just a matter of dropping the modules in the right
place. For purposes like this, a simple installer (as opposed to a
builder) would suffice. AFAIK, M::I tries to be just that: an
installer. And, as already noticed, it includes its code in the kit so
it doesn't need any modules pre-installed.

Do you have plans to support something in the style of File::ShareDir?

-- Johan

Re: [Module::Build] Asking the unaskable

[Johan V. <jvr...@sq...>]

Tyler MacDonald <ty...@yi...> writes:

> 	I havent tried it yet, but i've been keeping my eyes on App::Build:
>
> 	http://search.cpan.org/~spadkins/App-Build-0.62/lib/App/Build.pm
>
> 	It's a subclass of Module::Build that adds extra bells and whistles
> to support application (versus module) building.

Yes, it looks promising, though it seems to have some problems as
well.

-- Johan

[Module::Build] Re: Module::Build 0.27_09 -> CPAN

[Dominic D. <sho...@ma...>]

On 2006=9603=9614, at 03:02, Randy W. Sims wrote:
> Attached is a working (not final) patch that works for me on =20
> FreeBSD, Ubuntu Linux, Windows XP, and cygwin. Could you please =20
> give it a spin?

How's this getting along? Even though change 27531, Upgrade to =20
ExtUtils::CBuilder 0.17, cuts the number of failures on Mac OS X from =20=

seven to two, testing still produces a vast number of warnings -- see =20=

the attached file.

The provisional patch you posted in the mail I'm replying to had a =20
better effect, making all tests pass and suppressing all warnings.

--=20
Dominic Dunlop

Re: [Module::Build] Asking the unaskable

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

> >I'm writing this new and flashy application (some scripts, modules,
> >and data -- pure perl). Should I use ExtUtils::MakeMaker,
> >Module::Build or Module::Install?

	I havent tried it yet, but i've been keeping my eyes on App::Build:

	http://search.cpan.org/~spadkins/App-Build-0.62/lib/App/Build.pm

	It's a subclass of Module::Build that adds extra bells and whistles
to support application (versus module) building.

	Cheers,
		Tyler

Re: [Module::Build] Asking the unaskable

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

On Mar 17, 2006, at 8:34 AM, Johan Vromans wrote:

> I'm writing this new and flashy application (some scripts, modules,
> and data -- pure perl). Should I use ExtUtils::MakeMaker,
> Module::Build or Module::Install?

You realize you've walked into a lion's den and asked whether meat or  
eggplant tastes better, right? =)

One concrete area where M::B has an advantage is its ability to add  
custom installable components to the mix.  That's tough to do in a  
flexible way with MakeMaker.

See the "ADVANCED RECIPES" in http://search.cpan.org/~kwilliams/ 
Module-Build-0.27_09/lib/Module/Build/Cookbook.pm .

I'm unfortunately not very well-versed in Module::Install, so I  
probably can't comment too much about it.

  -Ken

Re: [Module::Build] How to I specify in META.yml a package needs a C compiler?

[R. B. <ro...@pa...>]

Ken Williams writes:
 > 
 > On Mar 16, 2006, at 9:57 PM, R. Bernstein wrote:
 > 
 > > dlisp options from Kobe's CPAN search I think use META.yml and
 > > META.yml is set via Module::Build. I have a package that requires a C
 > > compiler, but dlisp/META.ymal doesn't show that. How do I specify that
 > > (e.g. in Build.PL)?
 > 
 > There's currently no field in META.yml that indicates whether a C  
 > compiler is needed.  It's a pretty good idea, though.  In any case,  
 > the DLSP options must be coming from somewhere else.

Got it. Thanks for the information! 

I see how I was misled. Near the dslip (not dlisp) info was a FAQ
button: http://cpan.uwinnipeg.ca/htdocs/faqs/faq.html#04

And in that is:

   Why are some, or all, of the package prerequisites missing?

     Information for the prerequisites is extracted from a file
     META.yml within a distribution. Not all distributions have this
     file, as it is generated when making a distribution only with
     relatively recent version of either ExtUtils::MakeMaker or
     Module::Build

I now realize that this refers only to *package* prerequisites. Any
thoughts about extending Module::Build to produce this dslip thing?
(Just curious. In the meanwhile of course I'll just try to provide one
as a separate file.)

Best as I can tell the documentation for it is:
  http://cpan.uwinnipeg.ca/htdocs/faqs/dslip.html