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

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

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

On 2/17/06, demerphq <dem...@gm...> wrote:
> On 2/16/06, Ken Williams <ke...@ma...> wrote:
> >
> > On Feb 16, 2006, at 3:46 PM, demerphq wrote:
> >
> > >
> > > Id be happy to test what you did and/or to put a new patch together
> > > against a more recent version if you would prefer that.
> >
> > Thanks.  I did apply it, can you see whether CVS behaves as you expect?
> > Ideally we'd also get some regression tests, but I'm not sure really
> > what to be testing so I can't really write them myself.
>
> It seems fine. Output below. I think the attached patch should be
> applied as it might break existing frameworks where the batch files
> are called directly.  I was overenethusiastic there, sorry. I have no
> idea what to do about the final warning message. Its harmless so
> probably should just be documented as a win32 quirk somewhere. As for
> regression tests, isn't this already existing and tested behaviour
> pretty well?

And heres the latest pathtools as installed with the EU::Install patch
I sent out a while back.

Yves

cpan> install KWILLIAMS/PathTools-3.16.tar.gz
Running make for K/KW/KWILLIAMS/PathTools-3.16.tar.gz
CPAN: Digest::MD5 loaded ok
Checksum for /dev/MIRROR/MINICPAN/authors/id/K/KW/KWILLIAMS/PathTools-3.16.=
tar.gz
ok
PathTools-3.16/
PathTools-3.16/Build.PL
PathTools-3.16/Changes
PathTools-3.16/Cwd.pm
PathTools-3.16/Cwd.xs
PathTools-3.16/INSTALL
PathTools-3.16/lib/
PathTools-3.16/lib/File/
PathTools-3.16/lib/File/Spec/
PathTools-3.16/lib/File/Spec/Cygwin.pm
PathTools-3.16/lib/File/Spec/Epoc.pm
PathTools-3.16/lib/File/Spec/Functions.pm
PathTools-3.16/lib/File/Spec/Mac.pm
PathTools-3.16/lib/File/Spec/OS2.pm
PathTools-3.16/lib/File/Spec/Unix.pm
PathTools-3.16/lib/File/Spec/VMS.pm
PathTools-3.16/lib/File/Spec/Win32.pm
PathTools-3.16/lib/File/Spec.pm
PathTools-3.16/Makefile.PL
PathTools-3.16/MANIFEST
PathTools-3.16/META.yml
PathTools-3.16/ppport.h
PathTools-3.16/SIGNATURE
PathTools-3.16/t/
PathTools-3.16/t/crossplatform.t
PathTools-3.16/t/cwd.t
PathTools-3.16/t/Functions.t
PathTools-3.16/t/lib/
PathTools-3.16/t/lib/Test/
PathTools-3.16/t/lib/Test/Builder.pm
PathTools-3.16/t/lib/Test/More.pm
PathTools-3.16/t/lib/Test/Simple.pm
PathTools-3.16/t/lib/Test/Tutorial.pod
PathTools-3.16/t/rel2abs2rel.t
PathTools-3.16/t/Spec.t
PathTools-3.16/t/taint.t
PathTools-3.16/t/tmpdir.t
PathTools-3.16/t/win32.t

  CPAN.pm: Going to build K/KW/KWILLIAMS/PathTools-3.16.tar.gz

Checking if your kit is complete...
Looks good
Writing Makefile for Cwd

Microsoft (R) Program Maintenance Utility Version 7.00.9955
Copyright (C) Microsoft Corporation.  All rights reserved.

cp lib/File/Spec/Mac.pm blib\lib\File\Spec\Mac.pm
cp lib/File/Spec/OS2.pm blib\lib\File\Spec\OS2.pm
cp lib/File/Spec/VMS.pm blib\lib\File\Spec\VMS.pm
cp lib/File/Spec/Cygwin.pm blib\lib\File\Spec\Cygwin.pm
cp lib/File/Spec/Epoc.pm blib\lib\File\Spec\Epoc.pm
cp lib/File/Spec/Functions.pm blib\lib\File\Spec\Functions.pm
cp lib/File/Spec.pm blib\lib\File\Spec.pm
cp Cwd.pm blib\lib\Cwd.pm
cp lib/File/Spec/Unix.pm blib\lib\File\Spec\Unix.pm
cp lib/File/Spec/Win32.pm blib\lib\File\Spec\Win32.pm
        D:\ASPerl\811\bin\perl.exe D:\ASPerl\811\lib\ExtUtils\xsubpp=20
-typemap D:\ASPerl\811\lib\ExtUtils\typemap  Cwd.x
s > Cwd.xsc && D:\ASPerl\811\bin\perl.exe -MExtUtils::Command -e mv
Cwd.xsc Cwd.c
        cl -c    -nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -D
PERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO
-DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -O1    -DVERSION=3D\"3.16\"
 -DXS_VERSION=3D\"3.16\"  "-ID:\ASPerl\811\lib\CORE"   Cwd.c
Cwd.c
Running Mkbootstrap for Cwd ()
        D:\ASPerl\811\bin\perl.exe -MExtUtils::Command -e chmod 644 Cwd.bs
        D:\ASPerl\811\bin\perl.exe -MExtUtils::Mksymlists  -e
"Mksymlists('NAME'=3D>\"Cwd\", 'DLBASE' =3D> 'Cwd', 'DL_FUNCS'
 =3D> {  }, 'FUNCLIST' =3D> [], 'IMPORTS' =3D> {  }, 'DL_VARS' =3D> []);"
        link -out:blib\arch\auto\Cwd\Cwd.dll -dll -nologo
-nodefaultlib -debug -opt:ref,icf  -libpath:"D:\ASPerl\811\lib
\CORE"  -machine:x86 Cwd.obj   D:\ASPerl\811\lib\CORE\perl58.lib
oldnames.lib kernel32.lib user32.lib gdi32.lib winspool
.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib=20
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib -def:Cwd.def
   Creating library blib\arch\auto\Cwd\Cwd.lib and object
blib\arch\auto\Cwd\Cwd.exp
        D:\ASPerl\811\bin\perl.exe -MExtUtils::Command -e chmod 755
blib\arch\auto\Cwd\Cwd.dll
        D:\ASPerl\811\bin\perl.exe -MExtUtils::Command -e cp Cwd.bs
blib\arch\auto\Cwd\Cwd.bs
        D:\ASPerl\811\bin\perl.exe -MExtUtils::Command -e chmod 644
blib\arch\auto\Cwd\Cwd.bs
  C:\dotNet\Vc7\bin\nmake.EXE  -- OK
Running make test

Microsoft (R) Program Maintenance Utility Version 7.00.9955
Copyright (C) Microsoft Corporation.  All rights reserved.

        D:\ASPerl\811\bin\perl.exe "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib\lib', 'blib\arch')" t/*.t
t/crossplatform....ok
        7/50 skipped: Can't load File::Spec::VMS
t/cwd..............ok
        2/30 skipped: no symlinks on this platform
t/Functions........ok
t/rel2abs2rel......ok
t/Spec.............ok
        83/474 skipped: various reasons
t/taint............ok
t/tmpdir...........ok
t/win32............ok
All tests successful, 92 subtests skipped.
Files=3D8, Tests=3D584,  1 wallclock secs ( 0.00 cusr +  0.00 csys =3D  0.0=
0 CPU)
  C:\dotNet\Vc7\bin\nmake.EXE test -- OK
Running make install

Microsoft (R) Program Maintenance Utility Version 7.00.9955
Copyright (C) Microsoft Corporation.  All rights reserved.

Full installation will not be complete until next reboot.
However it is not necessary to reboot immediately.
Can't remove existing 'D:\ASPerl\811\lib\auto\Cwd\Cwd.dll': Permission deni=
ed
However it has been renamed as
'D:\ASPerl\811\lib\auto\Cwd\Cwd.dll.AAA' which will be removed at next
boot.
Installing D:\ASPerl\811\lib\auto\Cwd\Cwd.dll
Installing D:\ASPerl\811\lib\auto\Cwd\Cwd.exp
Installing D:\ASPerl\811\lib\auto\Cwd\Cwd.lib
Installing D:\ASPerl\811\lib\auto\Cwd\Cwd.pdb
Files found in blib\arch: installing files in blib\lib into
architecture dependent library tree
Installing D:\ASPerl\811\lib\Cwd.pm
Installing D:\ASPerl\811\lib\File\Spec.pm
Installing D:\ASPerl\811\lib\File\Spec\Cygwin.pm
Installing D:\ASPerl\811\lib\File\Spec\Unix.pm
Installing D:\ASPerl\811\lib\File\Spec\VMS.pm
Installing D:\ASPerl\811\lib\File\Spec\Win32.pm
Writing D:\ASPerl\811\lib\auto\Cwd\.packlist
Appending installation info to D:\ASPerl\811\lib/perllocal.pod
  C:\dotNet\Vc7\bin\nmake.EXE install UNINST=3D1 -- OK

cpan>

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

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

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

On Feb 16, 2006, at 4:32 PM, demerphq wrote:

> On 2/16/06, Ken Williams <ke...@ma...> wrote:
>>
>> On Feb 16, 2006, at 3:46 PM, demerphq wrote:
>>
>>>
>>> Id be happy to test what you did and/or to put a new patch together
>>> against a more recent version if you would prefer that.
>>
>> Thanks.  I did apply it, can you see whether CVS behaves as you 
>> expect?
>>   Ideally we'd also get some regression tests, but I'm not sure really
>> what to be testing so I can't really write them myself.
>
> Cvs access is not er, convenient. :-)
>
> Can i have a tar.gz to do build and install?

I'll send a tarball under separate cover.

  -Ken

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

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

On 2/16/06, Ken Williams <ke...@ma...> wrote:
>
> On Feb 16, 2006, at 3:46 PM, demerphq wrote:
>
> >
> > Id be happy to test what you did and/or to put a new patch together
> > against a more recent version if you would prefer that.
>
> Thanks.  I did apply it, can you see whether CVS behaves as you expect?
>   Ideally we'd also get some regression tests, but I'm not sure really
> what to be testing so I can't really write them myself.

Cvs access is not er, convenient. :-)

Can i have a tar.gz to do build and install? Or can put it on CPAN?
The latest i see is

 167801 2006-02-02 KWILLIAMS/Module-Build-0.27_07.tar.gz

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

Re: [Module::Build] Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMakerin5.8.8 for UINST=1

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

On Thu, 16 Feb 2006 07:27:13 -0500, Rob Kinyon wrote:

Hi Rob

> 2) The Win32-capable among us should be providing some direction as
> to the tools we're not using. If you know a shareware author, find

http://www.jrsoftware.org/isinfo.php

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

Re: [Module::Build] Re: Recursive Builds

[Nick Ing-S. <ni...@in...>]

Ken Williams <ke...@ma...> writes:
>On Feb 16, 2006, at 1:52 PM, Nick Ing-Simmons wrote:
>> So in both cases the descendants cannot run without the parent,
>> and need parent's blib etc. about to run their tests.
>> Parent has some tests of its own. Different children can be
>> built and tested without siblings being built/present.
>
>The main problem I see with this approach is what happens when you=20
>'install' from a child directory.=20=20

I agree that makes no sense in this scheme.=20
In the MakeMaker world there is nothing in child blib so=20
install in there has nothing to copy and is naturally a no-op.
I would be happy to put an explict install-does-nothing over-ride=20
in child Build.PL file(s).

>You've tested with other blibs=20
>active, but I'm hearing people say an 'install' here should only=20
>install the child stuff, so there's a good chance things will be broken=20
>after installing since it tested with different sibling code.
>
>I can think of a few solutions to this=20

Such as? (appologies if they have been discussed already...)

>but none so far that seem to=20
>satisfy all the use cases.

I suspect that there are "a few" typical cases e.g.:

A. A bundle of more or less unrelated modules put in a tree
   for convienience of building whole or sub-projects.

B. Toplevel + a "library" subdir that builds a .a file for=20
   toplevel. e.g. Compress::Zlib could have "the" open-source zlib=20
   distribution as a child dir with addition of a Build.PL to build=20
   libz.a if system didn't have -lz

C. Framework module (like Tk or DBI) with tightly coupled=20
   sub-dirs.

Tk itself has all those elements but is (I hope!) not typical.

So we need a "few" kinds of child Build.PL - an un-adorned one=20
could handle the "simpl" (A) case, with specialist cases being handled=20
by overrides of some kind.




>
>  -Ken

Re: [Module::Build] Re: Recursive Builds

[alan <al...@pa...>]

On Thu, 16 Feb 2006, Ken Williams wrote:

> On Feb 16, 2006, at 1:52 PM, Nick Ing-Simmons wrote:
> > So in both cases the descendants cannot run without the parent,
> > and need parent's blib etc. about to run their tests.
> > Parent has some tests of its own. Different children can be
> > built and tested without siblings being built/present.
>
> The main problem I see with this approach is what happens when you
> 'install' from a child directory.  You've tested with other blibs
> active, but I'm hearing people say an 'install' here should only
> install the child stuff, so there's a good chance things will be broken
> after installing since it tested with different sibling code.

One proposed solution for this which came up in the "recursive build"
thread in early 2004 was to distinguish between "developer mode" and
"end user mode," and to disallow end users from shooting their foot off
unless they explicitly put on a "developer" hat. Developers deserve to
get what they ask for.

In my personal experience with recursive builds in large/deep project
trees, the developer time saved in a build-test cycle is substantial, if
you can manually build/test/install the two dependant directories
separately, instead of having to build/test/install Everything from the
closest common ancestor in the build tree.

All of my recursive build requirements are specifically aimed at the
developer's development cycle, and not at end users; my end users are
insulated from the code. I agree that end users generally do not need to
do anything other than "./Build; ./Build test; ./Build install" at the
root (or, "choose some packages; ./Build install").


Alan Ferrency
pair Networks, Inc.
al...@pa...

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

demerphq <dem...@gm...> wrote:
> > That should make most people happy, no?
> 
> In general yes. But I think its worth considering that traditional is
> preferable. This
> 
>   http://perlmonks.org/index.pl?node_id=458282
> 
> argues that the traditional provides more flexibility for the end user.

	I think that argument is better solved by making
Module::Build::Compat should a bit more compatible. The main argument this
guy makes is that these modules aren't even using Module::Build's cool new
functionality...

		- Tyler

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 16, 2006, at 3:48 PM, demerphq wrote:

> In general yes. But I think its worth considering that traditional is
> preferable. This
>
>   http://perlmonks.org/index.pl?node_id=458282
>
> argues that the traditional provides more flexibility for the end user.

Yes.

  -Ken

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

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

On Feb 16, 2006, at 3:46 PM, demerphq wrote:

>
> Id be happy to test what you did and/or to put a new patch together
> against a more recent version if you would prefer that.

Thanks.  I did apply it, can you see whether CVS behaves as you expect? 
  Ideally we'd also get some regression tests, but I'm not sure really 
what to be testing so I can't really write them myself.

  -Ken

Re: [Module::Build] order of extra_compile_flags in compile_c

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

Hi Rocky,

Are you suggesting that in general the extra_compiler_flags should come  
after the default flags?  I think that's reasonable.  The change would  
have to be made in ExtUtils::CBuilder though, yes?

  -Ken

On Feb 16, 2006, at 11:27 AM, R. Bernstein wrote:

> I recently used Module::Build in my first CPAN project
> (Device:Cdio). This is a OO Perl wrapper for my libcdio library and I
> used SWIG to help me. (See ticket 17666 on rt.cpan.org; and many
> thanksfor considering as an inclusion this after the next M:B
> release.)
>
> One thing that came up in this endeavor was the order or the C flags
> in the compilation (compile_c).  It is helpful to turn off some gcc
> warning messages until such time SWIG is fixed to not cause gcc to
> emit them. So I changed the order of applying user cflags
> (extra_compiler_flags) to come *after* the cflags that are picked up
> as part of the Perl configuration (via Config). Another possibility is
> to add a new option to allow cflags specified before *and* afterwards.
>
> (If this is something I should add a ticket for in rt.cpan.org, let me
> know.)
>
> Thanks.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log  
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

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

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

On 2/16/06, Ken Williams <ke...@ma...> wrote:
> Let me reconsider my reasoning here from scratch.  The original point
> that Adam & Yves were making, IIUIC, was that distributions should
> include a Makefile.PL.  If they don't have one at all, then of course
> we don't need to worry about clobbering one!  So I'd be fine with
> changing the default in this case to provide some flavor of Makefile.PL
> generated in the dist directory.

Yes that was my point.

> The main question would be what style to make it.  'traditional' is
> accessible by more people, but will often be broken (if, e.g., there
> are config questions or auto-sensing in the Build.PL they'll be lost to
> the Makefile.PL), so I'd be inclined to choose 'small' or 'passthrough'
> for this case.
>
> That should make most people happy, no?

In general yes. But I think its worth considering that traditional is
preferable. This

  http://perlmonks.org/index.pl?node_id=3D458282

argues that the traditional provides more flexibility for the end user.

Cheers,
yves

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

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

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

On 2/16/06, Ken Williams <ke...@ma...> wrote:
>
> On Feb 15, 2006, at 4:29 AM, demerphq wrote:
>
> > On 2/14/06, Ken Williams <ke...@ma...> 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 though i did provide a patch for the Build.bat issue.
>
> Yes, it's been applied now but I'll need some help making sure it's
> correct because I couldn't apply it cleanly.  Once we confirm that and
> get version.pm stuff working (so that core isn't broken) and get some
> testing reports back (which probably means another beta) we can release
> 0.28.  But no other features besides those.

Id be happy to test what you did and/or to put a new patch together
against a more recent version if you would prefer that.=20
(unfortunately im on holiday for a week starting saturday so if you
want a new patch it would probably have to wait.)

Yves

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

[Module::Build] Re: extra_dirs feature: should I contribute a patch to Module::Build?

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

Hi,

I have written a module called App::Build which is derived from Module::Bui=
ld.
I put some features into it that I believe could and should be moved up to
Module::Build.  The description of App::Build is below.

My specific question at the moment is:
* Should I contribute a patch to add the "extra_dirs" feature to Module::Bu=
ild?
* (i.e. Is this a feature you want in Module::Build?)

Thanks,

Stephen

http://search.cpan.org/~spadkins/App-Build/lib/App/Build.pm
[excerpted below]

=3Dhead1 NAME

App::Build - extends Module::Build to build/install/configure entire
applications (i.e. web applications), not just modules and programs

=3Dhead1 SYNOPSIS

 This module is used within a Build.PL script directly or
 it can be subclassed to provide extra capabilities.

 use App::Build;

 my $build =3D App::Build->new (
     dist_name         =3D> "App-Build-Foo",
     dist_version      =3D> "1.0",
     dist_author       =3D> "spa...@gm...",
     extra_dirs        =3D> [ "htdocs", "cgi-bin", "etc", "var" ],
     license           =3D> "perl",
     build_requires =3D> {
         "App::Build"  =3D> 0,  # needed for installing the software
     },
 );

 $build->create_build_script;

=3Dhead1 DESCRIPTION

App::Build is a subclass of Module::Build, so you can use
it in place of Module::Build when creating your "Build.PL"
installation scripts.

Module::Build is good at
installing perl modules and programs/scripts.  Full applications
(i.e. web applications) need to install other files such as
web pages, images, CSS style sheets, javascript files,
CGI programs, data files, and configuration data.
App::Build addresses these issues.

The vision of App::Build is to make installing entirely
functional perl applications (particularly web applications)
as easy as installing individual modules from CPAN.

An ISP customer (or other unprivileged user)
who has shell access should be able to install any number
of available applications from CPAN simply by typing the
usual

 perl -MCPAN -e "install App::Build::Foo"

and the "Foo" application is installed on his account.

App::Build does this by implementing the following features.

[... intermediate doc deleted ...]

_get_extra_dirs()

Gets the list of extra_dirs to be installed.

The extra_dirs may be specified in the Build.PL in a variety of ways.
It can be a scalar (comma-separated list of directories), an array ref
of directories, or a hash ref where the keys are the directories.

If extra_dirs is specified with a hash ref, the hash values are
hashrefs of attributes. i.e.

  extra_dirs =3D> {
      var =3D> {
          dest_dir =3D> "var",
      },
      htdocs =3D> {
          dest_dir =3D> "htdocs",
      },
      "cgi-bin" =3D> {  # any dir ending in "bin" contains executable scrip=
ts
          dest_dir =3D> "cgi-bin",
      },
      support =3D> {
          dest_dir =3D> "support",
          executable =3D> 1,  # treat contents as executable scripts
      },
  },

[... for complete/further doc, follow the URL given above ...]

Re: [Module::Build] Re: Recursive Builds

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

On Feb 16, 2006, at 1:52 PM, Nick Ing-Simmons wrote:
> So in both cases the descendants cannot run without the parent,
> and need parent's blib etc. about to run their tests.
> Parent has some tests of its own. Different children can be
> built and tested without siblings being built/present.

The main problem I see with this approach is what happens when you 
'install' from a child directory.  You've tested with other blibs 
active, but I'm hearing people say an 'install' here should only 
install the child stuff, so there's a good chance things will be broken 
after installing since it tested with different sibling code.

I can think of a few solutions to this but none so far that seem to 
satisfy all the use cases.

  -Ken

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

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

On Feb 16, 2006, at 11:54 AM, David Wheeler wrote:

> On Feb 16, 2006, at 09:49, Ken Williams wrote:
>
>> I don't have such a link, but essentially any info sent to 
>> STDERR/STDOUT during testing is lost because CPANPLUS calls the 
>> 'test' action through the M::B API, not in a subprocess like it does 
>> for EU::MM, and doesn't capture those filehandle outputs.
>
> Oh. That should be easy to fix with a tied or piped file handle. 
> Test::Output has the code that's needed.

Agreed - it's just that until we write a failing test case and see it 
squashed I can't be completely sure that the fix is only in CP+ (and 
its CP+::Dist::Build connector) and not also in M::B.  If it's only 
over in CP+-land, great.

  -Ken

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

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

On Feb 16, 2006, at 12:08 PM, John Peacock wrote:

> Ken Williams wrote:
>> On Feb 16, 2006, at 11:46 AM, John Peacock wrote:
>>> Is there some overriding reason you are avoiding upgrading the YAML 
>>> prereq to 0.50 (which in itself isn't even the current rev)?
>> Good question.  I guess not, though this is the first time I think 
>> we'd upgrade an auto-feature dependency, and it has just occurred to 
>> me that it'll catch people by surprise if they currently have that 
>> feature enabled.  It will suddenly get non-enabled without much 
>> warning.
>
> Can't the 0.28 installer test for the auto-feature already being 
> enabled *and* whether YAML is new enough and then upgrade that to a 
> mandatory prereq?

Yup, it could, and it probably should.  I'd just never thought of it 
before this thread so it doesn't do it yet, and to make things DTRT we 
should really think through various contingencies - such as what 
happens when the user has a previously-acceptable YAML installed and is 
willing to turn off the feature because they don't want to upgrade.  I 
think the various cases could get tricky.

I'd prefer to keep the declaration of 'auto_features' purely 
declarative, and have the checker implement all the necessary decisions 
rather than sticking functions into the declarations, though.

  -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 16, 2006, at 2:05 PM, Chris Dolan wrote:

> Attached below is a regexp-based solution that matches "simple" 
> Build.PL files.  I submit this just for thought, not necessarily for 
> inclusion in M::B.

Cool.  I wonder if Randy Sims (when he gets back from vacation) could 
run this against his mini-cpan area to get some statistics on the 
broader CPAN.  Or anyone else, if they're so inclined, certainly.

> Perhaps this mode could be triggered by C<create_makefile_pl => 
> 'automatic'>

Yeah.  As long as we're very strict in how we parse, i.e. any "syntax 
errors" according to our grammar for simple Build.PL files are "fatal", 
this does seem like a good way to do things.

I would initially like to roll out the 'auto' default without any of 
this sensing on the Build.PL, but it's going to be good to have in our 
back pocket.  Thanks.

  -Ken

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 16, 2006, at 11:53 AM, Ken Williams wrote:

> On Feb 16, 2006, at 11:45 AM, Tyler MacDonald wrote:
>
>> 	I think "passthrough" is the way to go here. I also still think that
>> if we default in some way to generating a Makefile.PL,  
>> create_makefile_pl
>> should be extended to have an explicit "skip" option as well.
>
> Definitely.  I'd just change the default to 'auto' (which means  
> create a 'small' [or 'passthrough'] Makefile.PL if none already  
> exists) though, and then the author can explicitly put  
> "create_makefile_pl => 0" (or any other false value) in their  
> Build.PL to shut it off.
>
> If in the future we figure out how to auto-sense when we could  
> create a 'traditional' Makefile.PL that would be cool, but I don't  
> really see it happening.  Too hard.
>
>  -Ken

Attached below is a regexp-based solution that matches "simple"  
Build.PL files.  I submit this just for thought, not necessarily for  
inclusion in M::B.

Inline below are the results of running my program against a bunch of  
CPAN packages.  This demonstrates that many CPAN modules use "simple"  
Build.PL files. If (and that's a big if) we decided to use a code- 
matcher like what I've written, we could detect simple Build.PL files  
and decide on the fly if a "traditional" Makefile.PL is appropriate.   
Perhaps this mode could be triggered by C<create_makefile_pl =>  
'automatic'>

One could imagine that PPI would be a good tool to perform this code  
analysis.

% perl simple_build_pl ~/.cpanplus/5.8.6/build/*/Build.PL
simple  Array-Compare-1.13/Build.PL
simple  CAM-DBF-1.01/Build.PL
simple  CAM-EmailTemplate-SMTP-0.91/Build.PL
complex CAM-PDF-1.03/Build.PL
simple  CAM-SQLManager-1.13/Build.PL
simple  CAM-SQLObject-1.01/Build.PL
simple  CAM-Session-1.03/Build.PL
simple  CAM-Template-0.93/Build.PL
simple  CAM-Template-Cache-0.91/Build.PL
simple  CAM-XML-1.13/Build.PL
simple  CGI-Compress-Gzip-0.21/Build.PL
simple  Class-Accessor-Chained-0.01/Build.PL
simple  Class-Std-0.0.4/Build.PL
simple  Config-Std-0.0.2/Build.PL
complex DateTime-Locale-0.22/Build.PL
complex DateTime-TimeZone-0.40/Build.PL
simple  Devel-StackTrace-1.12/Build.PL
simple  Exception-Class-1.23/Build.PL
simple  ExtUtils-CBuilder-0.15/Build.PL
simple  FSA-Rules-0.23/Build.PL
complex File-Extract-0.06/Build.PL
simple  File-Find-Rule-0.28/Build.PL
simple  File-Find-Rule-Filesys-Virtual-1.21/Build.PL
simple  HTTP-Proxy-0.17/Build.PL
complex Image-Imlib2-1.07/Build.PL
complex Module-Build-0.27_06/Build.PL
simple  Module-CPANTS-Analyse-0.5/Build.PL
simple  Module-CPANTS-Generator-0.42/Build.PL
simple  Module-Depends-0.10/Build.PL
simple  Module-ExtractUse-0.17/Build.PL
simple  Module-Pluggable-2.96/Build.PL
simple  Module-Starter-PBP-0.0.2/Build.PL
simple  Net-DAV-Server-1.28/Build.PL
simple  Net-IP-Match-Regexp-0.93/Build.PL
simple  Net-VNC-0.30/Build.PL
simple  Parse-CPAN-Modlist-0.9/Build.PL
simple  Parse-CPAN-Packages-2.25/Build.PL
simple  Path-Class-0.15/Build.PL
complex PathTools-3.15/Build.PL
simple  Perl-Critic-0.13/Build.PL
simple  Perl-Metric-Basic-0.30/Build.PL
simple  Pod-Coverage-0.17/Build.PL
simple  Pod-FromActionscript-0.53/Build.PL
simple  Pod-Readme-0.05/Build.PL
simple  Pod-Strip-1.01/Build.PL
simple  SWF-NeedsRecompile-1.02/Build.PL
simple  Test-Distribution-1.23/Build.PL
simple  Test-Exception-0.21/Build.PL
simple  Test-MockObject-1.02/Build.PL
simple  Test-Perl-Critic-0.03/Build.PL
simple  UNIVERSAL-can-1.03/Build.PL
simple  UNIVERSAL-isa-0.05/Build.PL
complex version-0.53/Build.PL

Interestingly, two of the "complex" results were false positives  
because of typos in the Build.PL -- the file contained "author"  
instead of "dist_author"

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] extra_dirs feature: should I contribute a patch to Module::Build?

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

Hi,

I have written a module called App::Build which is derived from Module::Bui=
ld.
I put some features into it that I believe could and should be moved up to
Module::Build.  The description of App::Build is below.

My specific question at the moment is:
* Should I contribute a patch to add the "extra_dirs" feature to Module::Bu=
ild?
* (i.e. Is this a feature you want in Module::Build?)

Thanks,

Stephen

http://search.cpan.org/~spadkins/App-Build/lib/App/Build.pm
[excerpted below]

=3Dhead1 NAME

App::Build - extends Module::Build to build/install/configure entire
applications (i.e. web applications), not just modules and programs

=3Dhead1 SYNOPSIS

  This module is used within a Build.PL script directly or
  it can be subclassed to provide extra capabilities.

  use App::Build;

  my $build =3D App::Build->new (
      dist_name         =3D> "App-Build-Foo",
      dist_version      =3D> "1.0",
      dist_author       =3D> "spa...@gm...",
      extra_dirs        =3D> [ "htdocs", "cgi-bin", "etc", "var" ],
      license           =3D> "perl",
      build_requires =3D> {
          "App::Build"  =3D> 0,  # needed for installing the software
      },
  );

  $build->create_build_script;

=3Dhead1 DESCRIPTION

App::Build is a subclass of Module::Build, so you can use
it in place of Module::Build when creating your "Build.PL"
installation scripts.

Module::Build is good at
installing perl modules and programs/scripts.  Full applications
(i.e. web applications) need to install other files such as
web pages, images, CSS style sheets, javascript files,
CGI programs, data files, and configuration data.
App::Build addresses these issues.

The vision of App::Build is to make installing entirely
functional perl applications (particularly web applications)
as easy as installing individual modules from CPAN.

An ISP customer (or other unprivileged user)
who has shell access should be able to install any number
of available applications from CPAN simply by typing the
usual

  perl -MCPAN -e "install App::Build::Foo"

and the "Foo" application is installed on his account.

App::Build does this by implementing the following features.

[... intermediate doc deleted ...]

_get_extra_dirs()

Gets the list of extra_dirs to be installed.

The extra_dirs may be specified in the Build.PL in a variety of ways.
It can be a scalar (comma-separated list of directories), an array ref
of directories, or a hash ref where the keys are the directories.

If extra_dirs is specified with a hash ref, the hash values are
hashrefs of attributes. i.e.

   extra_dirs =3D> {
       var =3D> {
           dest_dir =3D> "var",
       },
       htdocs =3D> {
           dest_dir =3D> "htdocs",
       },
       "cgi-bin" =3D> {  # any dir ending in "bin" contains executable scri=
pts
           dest_dir =3D> "cgi-bin",
       },
       support =3D> {
           dest_dir =3D> "support",
           executable =3D> 1,  # treat contents as executable scripts
       },
   },

[... for complete/further doc, follow the URL given above ...]

[Module::Build] Re: Recursive Builds

[Nick Ing-S. <ni...@in...>]

Nick Ing-Simmons <ni...@in...> writes:
>>That discussion is happening on the Module-Build list even now.=20=20
>
>Hmm, my subscription to that list seems to have gone AWOL.

Now repaired but I can't think of a way to get this spliced into=20
existing thread.

So here is what I said on perl5-porters:

>
>>The=20
>>problem is that what "nested build" means is different for different=20
>>people.  Personally, I'd like blib/lib and blib/arch to contain all sub=
=20
>>blib's below the current one (strictly speaking a recursive build).  And=
=20
>>at any level, a './Build command' will run all lower level ./Build files=
=20
>>with the same command depth-first.
>
>That is roughly what my Tk and Audio::* want as well.
>The potential issue is when the depth-first part kicks in.
> - The Build.PL process needs to be top down so that toplevel Build.PL
>   can do the confugure-like tests needed by the children.=20
> - I have no trouble with actual build being depth first.
> - I need to control the order of child builds somehow, this could=20
>   be by tweaking the depth !
>
>e.g. for Tk:
> - Toplevel Build.PL figures out where Xlib lib and inc are.=20
> - One special child is pTk which is wrapper on core tk
> - other descendants are the major widgets.
>=20=20
>For Audio (::Data et. al)
> - Top level Build.PL decides which children _can_ be built
>   i.e. what audio hardware we have and which math and file format libs
>   are available.
> - Child builds are more-or-less independant
>

So in both cases the descendants cannot run without the parent,
and need parent's blib etc. about to run their tests.
Parent has some tests of its own. Different children can be=20
built and tested without siblings being built/present.

In this scheme a branch of tree can be lopped off or a new one=20
grafted on.=20

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

[<in...@tt...>]

Ken,

You definitely want to use 0.58+ for your prereqs.

For a couple of 0.5x releases there were Spiffy deps etc, but that's all been
resolved. Now YAML.pm requires no extra deps.

Also with 0.58 I can fix bugs and turn around releases in short order (well
depending on the bug ;)

Cheers, Ingy

On 16/02/06 11:55 -0600, Ken Williams wrote:
> 
> On Feb 16, 2006, at 11:46 AM, John Peacock wrote:
> 
> >Is there some overriding reason you are avoiding upgrading the YAML 
> >prereq to 0.50 (which in itself isn't even the current rev)?
> 
> Good question.  I guess not, though this is the first time I think we'd 
> upgrade an auto-feature dependency, and it has just occurred to me that 
> it'll catch people by surprise if they currently have that feature 
> enabled.  It will suddenly get non-enabled without much warning.
> 
>  -Ken
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Yaml-core mailing list
> Yam...@li...
> https://lists.sourceforge.net/lists/listinfo/yaml-core

[Module::Build] Re: Summary was: Re: something broken between Module::Build, CPAN.pm, and ExtUtils::MakeMaker

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

On 2/16/06, Tels <nos...@bl...> wrote:
> Moin,
>
> the thread has grown a lot and spuried a lot of discussion, but I think
> there is still a lot of cross talk and people confusing things.
>
> Here is a quick summary - it hopefully clears the confusion[7] :-P
>
> For any module, especially the ones for installing other modules (e.g.
> M::B, EUMM, M::I and CPAN) there are three (not nec. distinctive) crowds:
>
>   * A - the original source code author and maintainer.[0]
>   * D - developers, e.g. other people who want (or must, via dependencies=
)
>     use the module in their code. Often includes A, too.
>   * U - mere users, who just want (or must, see above) to _use_ the
>     module's functionality. Can also include A and D.
>
> Fact of the Day:
>  Any module which wants to replace the current build system (EUMM) must
>  please[8] all three crowds or it will fail.[1]
>
> Pleasing U does, among other things, require to solve the chicken-egg
> problem.
>
> What Module::Build claims is that it pleases A and D. From that is infere=
d
> that U will also be automatically pleased. That assumption doesn't
> hold, tho.[2] Or it is claimed that U is also pleased.
>
> So, we have critism from U about not being pleased (Adam writes about
> this, for instance). To this there are responses along the lines:
>
> * U might be displeased or not, but D is very pleased[4]:
>   http://tinyurl.com/du7yc
>   Bzzzt. Wrong answer.
>
> * U is pleased:
>    "M::B based distros are easy for users to build & install." --
>     Randy W. Sims - http://tinyurl.com/9aob9
>   Bzzzt, wrong answer (or we wouldn't have the discussion!).
>
> * CYJU (CantYouJustUse)[3] CPAM.pm (or update whatever) - that just works
>   around the chicken-egg problem by saying "build a nest and the chicken
>   can lay the egg" - sorry :). It's nice when it works, but doesn't gain
>   anything when it doesn't[5] because it doesn't solve the underlying
>   problem.
>   See for instance: http://tinyurl.com/dltze
>
> So, Advice of the Day: don't mix the crowds and don't assume everyone is
> in the same crowd as you are. And don't sidestep questions, or deny that
> the problem exists. :)
>
> It is also worth noting that the U crowd is much bigger than A+D, which
> should be a sure sign that ignoring them spells doom in big red letters.
> [6] This doesn't mean you can ignore A and D's pleasing, tho.
>
> Best wishes,
>
> Tels
>
> 0: This includes the maintainer(s), because these are often the same, and
>    most, if not all problems apply to both of them.
> 1: This means that if A+D are pleased, but U not, we fail.
> 2: Sure, if A and/or D are so displaesed that they jump from a bridge, yo=
u
>    end up with a big mess and U cannot expect new features and/or delays.
>    However, if the current solution "works" for most in U, then replacing
>    it by a new solution doesn't "please" them - they are already happy. S=
o
>    if we displease U a bit to please the A+D crowd, we also fail.
> 3: I just love that. It's a red flag in German IT circles, too: "Einfach
>    mal nur" or "mal schnell eben", where "eben" =3D=3D "just" and "schnel=
l" =3D=3D
>    fast and "einfach" =3D=3D simple and "mal" means "this time" or "one
>    time" (see http://dict.leo.org/?search=3Dmal)
> 4: Note: When writing complicated Makefile.PLs - this does apply only to =
a
>    subset of D.
> 5: Maybe because you have one of the buggy CPAN installations, or are
>    not connected to the net, or can't run CPAN (like on VMS). Or, or, or.
> 6: Don't tell me you are not in the U crowd - in the near future you will
>    want to use your own code and it might just fail for you to install.
> 7: Yves also wrote the same, but in a more long message where it might be
>    missed: http://tinyurl.com/7o6dd
> 8: "please" means: "makes things better, or at least not (much) more wors=
e
>    for them.

Wow tels!

I tried to write a summary like this, but failed to come up with
something that abstracts out the issues as well.

Thank you very much.

PS: I cc'ed the MB and EUMM folks on this. No good summarizing if all
the relevent people arent going to see it, but maybe me sending it is
for the beter anyway, as im on the MB list so it wont go into
moderator purgatory when it comes from me.


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

[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:
> John Peacock <jpe...@ro...> writes:
>> That discussion is happening on the Module-Build list even now.  
> 
> Hmm, my subscription to that list seems to have gone AWOL.

Mailman gets bored easily.  It's too bad that SF.net doesn't run ezmlm, 
so you will get a challenge email if things start bouncing for any reason.

> That is roughly what my Tk and Audio::* want as well.
> The potential issue is when the depth-first part kicks in.
>  - The Build.PL process needs to be top down so that toplevel Build.PL
>    can do the confugure-like tests needed by the children. 
>  - I have no trouble with actual build being depth first.
>  - I need to control the order of child builds somehow, this could 
>    be by tweaking the depth !

It may be possible to extend Build.PL so that if you need a specific 
execution order (or Build.PL execution order) then the toplevel file can 
impose that.  Otherwise a simple recursive tree walk collecting the 
sub-projects could be the default (cake->eat_too());

Ken already said that recursive builds are on the plate for post-0.28, 
so rejoin the M::B list for the cagematch^Wdiscussion, since you have 
insights that those of us with simple modules cannot dream of...

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

[Nick Ing-S. <ni...@in...>]

John Peacock <jpe...@ro...> writes:
>Nick Ing-Simmons wrote:
>> Chromatic <chr...@wg...> writes:
>>> M::B provides the minimal features to get the module built, tested, and=
=20
>>> installed.  The bare tarball doesn't.  No slope.
>>=20
>> I would like to switch to module build but AFAIK it still can't=20
>> do nested builds.
>
>That discussion is happening on the Module-Build list even now.=20=20

Hmm, my subscription to that list seems to have gone AWOL.

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

That is roughly what my Tk and Audio::* want as well.
The potential issue is when the depth-first part kicks in.
 - The Build.PL process needs to be top down so that toplevel Build.PL
   can do the confugure-like tests needed by the children.=20
 - I have no trouble with actual build being depth first.
 - I need to control the order of child builds somehow, this could=20
   be by tweaking the depth !

e.g. for Tk:
 - Toplevel Build.PL figures out where Xlib lib and inc are.=20
 - One special child is pTk which is wrapper on core tk
 - other descendants are the major widgets.
=20=20
For Audio (::Data et. al)
 - Top level Build.PL decides which children _can_ be built
   i.e. what audio hardware we have and which math and file format libs
   are available.
 - Child builds are more-or-less independant

>
>Is this what EUMM does now?=20=20

Yes - with the possible exception of the depth-first, for some meaning of=
=20
depth-first. It works for both cases above ;-)

>This seems to be what GNU automake/autoconf=20
>seems to expect.
>
>John

Re: [Module::Build] Re: [Yaml-core] yaml_dump on version objects

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

Ken Williams wrote:
> 
> On Feb 16, 2006, at 11:46 AM, John Peacock wrote:
> 
>> Is there some overriding reason you are avoiding upgrading the YAML 
>> prereq to 0.50 (which in itself isn't even the current rev)?
> 
> Good question.  I guess not, though this is the first time I think we'd 
> upgrade an auto-feature dependency, and it has just occurred to me that 
> it'll catch people by surprise if they currently have that feature 
> enabled.  It will suddenly get non-enabled without much warning.

Can't the 0.28 installer test for the auto-feature already being enabled 
*and* whether YAML is new enough and then upgrade that to a mandatory 
prereq?  It would mean that the auto_feature would still quote 0.35, but 
then before running create_build_script, you have to ask if they want to 
upgrade YAML *or* disable YAML support.  Alternatively, check the 
existing auto-feature setting before calling ModuleBuildBuilder and DTRT...

This may be something to consider for future development: conditional 
autofeatures that take a coderef for additional processing.  In pseudocode:

    auto_features => {
                      YAML_support =>
                      {
                       description => "Can write fully-functional 
META.yml files",
                       requires => { YAML => check_yaml() },
                      },

where check_yaml() returns either true (if the existing version is 
already acceptable) or can prompt the user and insert a new requires() 
stanza if the user accepts the additional dependency, *or* it returns 
false and that auto-feature is disable.

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