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

[Module-build-general] A better passthrough Makefile.PL

[Dave R. <au...@ur...>]

I wanted to create a Makefile.PL that would pass all functionality through
to Module::Build, _and_ that would make sure that Module::Build got
installed if necessary.  I also wanted to make sure that the user did not
have to run "perl Makefile.PL" twice, once for installing Module::Build,
and once to install the desired module.  Having to do this basically makes
the install fail with CPAN or CPANPLUS.

Here's what I came up with:


  use Cwd;
  use File::Spec;

  unless (eval { require Module::Build::Compat; 1 }) {
      require ExtUtils::MakeMaker;

      print "This module required Module::Build to install itself.\n";

      my $yn = ExtUtils::MakeMaker::prompt( '  Install Module::Build', 'y' );

      if ($yn =~ /^y(es)?/i) {
	  # save this cause CPAN will chdir all over the place.
	  my $cwd = cwd();
	  my $makefile = File::Spec->rel2abs($0);

	  require CPAN;
	  CPAN->install('Module::Build');

	  chdir $cwd
	      or die "Cannot chdir to $cwd: $!";

	  exec( $^X, $makefile, @ARGV )
      } else {
	  warn "Cannot install Thesaurus without Module::Build.  Exiting ...\n";
	  exit 0;
      }
  }

  require Module::Build::Compat;
  Module::Build::Compat->run_build_pl( args => \@args );
  Module::Build::Compat->write_makefile;

[Module-build-general] CVS sources now on SourceForge

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

Hi,

After a long delay from SourceForge (but who can look a gift 
horse in the mouth, really), the CVS sources for Module::Build 
are publically available:

  https://sourceforge.net/cvs/?group_id=45731

I'll probably continue to be the sole committer for a while, 
barring unforeseen external enthusiasm and so on.  A public CVS 
repository makes it easier for other people to submit patches 
and stay current with development, though.

  -Ken

[Module-build-general] Re: Module::Builder 0.11

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

Hi Dean,

Actually, it should really just be a zero-length file.  If you 
create it with zero-length, do the tests still succeed?

I think for the time being, I'll just put the single line 
"MANIFEST" in the file.  Eventually I'll be able to get rid of 
that file altogether, I think, which will be even better.

Thanks for the report.

  -Ken


On Monday, September 2, 2002, at 12:03 AM, Dean Wilson wrote:
> Hello Mr Williams
>   I have downloaded a copy of Module::Build version 0.11 from 
> CPAN and tried
> to unpack and run it on a Windows2000 (ServicePack3) desktop 
> and received
> the error:
>
> Warning: the following files are missing in your kit:
>         t/MANIFEST
>
> This file exists in the tar.gz with a zero length so it is not 
> correctly
> unzipped on a Windows machine, while this is a limitation on 
> Windows i had a
> look at the module's directory layout and i think that the MANIFEST
> file for t/ should look something like the attached. If the attached is
> correct then it fixes both the missing content in the MANIFEST 
> file and then
> the file will be created correctly on Win32 as its not zero length.
>
> Thank you for your time and a very promising module.
>
>   Dean
> --
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the postmaster at pos...@we....
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.webperform.com
> **********************************************************************
>
>

[Module-build-general] Re: FAIL Module-Build-0.11 cygwin-multi-64int 1.3.12(0.5432)

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

Hi Gerrit,

Thanks for this report.  I don't have access to cygwin, so it would be=20=

great if you have the time to help track this down.  Could you try=20
running this with verbose output, as

  ./Build test verbose=3D1

  (Or simply "perl -Mblib t/xs.t")

And see what the output is?  I'm interested to see what the compile/link=20=

commands look like.




On Friday, August 23, 2002, at 09:34  PM, Gerrit P. Haase wrote:

> This distribution has been tested as part of the cpan-testers
> effort to test as many new uploads to CPAN as possible.  See
> http://testers.cpan.org/
>
> Please cc any replies to cpa...@pe... to keep other
> test volunteers informed and to prevent any duplicate effort.
>
> --
>
> some tests fail
>
> Running make test
> ./Build test
> t/basic.........ok
> t/runthrough....ok
> t/xs............ok 3/6lib/XSTest.o(.text+0x2d):XSTest.c: undefined=20
> reference to =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x37):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x48):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x52):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x60):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x6a):XSTest.c: undefined reference to=20
> =1FPerl_Tmarkstack_ptr_ptr'
> lib/XSTest.o(.text+0x87):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x91):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0xbb):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0xcd):XSTest.c: undefined reference to =1FPerl_croak'=

> lib/XSTest.o(.text+0xd9):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0xe3):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x10c):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x116):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x13d):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x14b):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x155):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x174):XSTest.c: undefined reference to =
=1FPerl_sv_2iv'
> lib/XSTest.o(.text+0x189):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x193):XSTest.c: undefined reference to=20
> =1FPerl_Top_ptr'
> lib/XSTest.o(.text+0x1ab):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1b5):XSTest.c: undefined reference to=20
> =1FPerl_Tcurpad_ptr'
> lib/XSTest.o(.text+0x1c3):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1cd):XSTest.c: undefined reference to=20
> =1FPerl_Top_ptr'
> lib/XSTest.o(.text+0x1ef):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1f9):XSTest.c: undefined reference to=20
> =1FPerl_sv_newmortal'
> lib/XSTest.o(.text+0x21f):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x229):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x248):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x265):XSTest.c: undefined reference to=20
> =1FPerl_sv_setiv'
> lib/XSTest.o(.text+0x280):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x291):XSTest.c: undefined reference to =
=1FPerl_mg_set'
> lib/XSTest.o(.text+0x2a9):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x2b3):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x2c1):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x2cb):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x30a):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x314):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x322):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x32c):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x33a):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x344):XSTest.c: undefined reference to=20
> =1FPerl_Tmarkstack_ptr_ptr'
> lib/XSTest.o(.text+0x361):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x36b):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x395):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x3b6):XSTest.c: undefined reference to =
=1FPerl_newXS'
> lib/XSTest.o(.text+0x3c2):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x3cc):XSTest.c: undefined reference to=20
> =1FPerl_Isv_yes_ptr'
> lib/XSTest.o(.text+0x3da):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x3e4):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x401):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x40b):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x419):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x423):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> /bin/../lib/gcc-lib/i686-pc-
> cygwin/3.1.1/../../../libcygwin.a(libcmain.o)(.text+0x81): undefined=20=

> reference to =1FWinMain@16'
> collect2: ld returned 1 exit status
> # Failed test 4 in t/xs.t at line 28
> t/xs............NOK 4lib/XSTest.o(.text+0x2d):XSTest.c: undefined=20
> reference to =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x37):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x48):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x52):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x60):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x6a):XSTest.c: undefined reference to=20
> =1FPerl_Tmarkstack_ptr_ptr'
> lib/XSTest.o(.text+0x87):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x91):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0xbb):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0xcd):XSTest.c: undefined reference to =1FPerl_croak'=

> lib/XSTest.o(.text+0xd9):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0xe3):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x10c):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x116):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x13d):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x14b):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x155):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x174):XSTest.c: undefined reference to =
=1FPerl_sv_2iv'
> lib/XSTest.o(.text+0x189):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x193):XSTest.c: undefined reference to=20
> =1FPerl_Top_ptr'
> lib/XSTest.o(.text+0x1ab):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1b5):XSTest.c: undefined reference to=20
> =1FPerl_Tcurpad_ptr'
> lib/XSTest.o(.text+0x1c3):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1cd):XSTest.c: undefined reference to=20
> =1FPerl_Top_ptr'
> lib/XSTest.o(.text+0x1ef):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x1f9):XSTest.c: undefined reference to=20
> =1FPerl_sv_newmortal'
> lib/XSTest.o(.text+0x21f):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x229):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x248):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x265):XSTest.c: undefined reference to=20
> =1FPerl_sv_setiv'
> lib/XSTest.o(.text+0x280):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x291):XSTest.c: undefined reference to =
=1FPerl_mg_set'
> lib/XSTest.o(.text+0x2a9):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x2b3):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x2c1):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x2cb):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_base_ptr'
> lib/XSTest.o(.text+0x30a):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
> lib/XSTest.o(.text+0x314):XSTest.c: undefined reference to=20
> =1FPerl_Tstack_sp_ptr'
> lib/XSTest.o(.text+0x322):XSTest.c: undefined reference to=20
> =1FPerl_Gcurinterp_ptr'
>         Failed 2/6 tests, 66.67% okay
> Failed Test Stat Wstat Total Fail  Failed  List of Failed
> =
--------------------------------------------------------------------------=
---------------
> t/xs.t                     6    2  33.33%  4-5
> Failed 1/3 test scripts, 66.67% okay. 2/25 subtests failed, 92.00% =
okay.
> make: *** [test] Error 14
>   /bin/make test -- NOT OK
>
>
> --
>
> Summary of my perl5 (revision 5.0 version 8 subversion 0) =
configuration:
>   Platform:
>     osname=3Dcygwin, osvers=3D1.3.12(0.5432), =
archname=3Dcygwin-multi-64int
>     uname=3D'cygwin_nt-5.0 kmbestst 1.3.12(0.5432) 2002-07-06 02:16 =
i686=20
> unknown '
>     config_args=3D'-de -Dmksymlinks -Dusemultiplicity -Duse64bitint=20
> -Doptimize=3D-O2 -Dman3ext=3D3pm'
>     hint=3Drecommended, useposix=3Dtrue, d_sigaction=3Ddefine
>     usethreads=3Dundef use5005threads=3Dundef useithreads=3Dundef=20
> usemultiplicity=3Ddefine
>     useperlio=3Ddefine d_sfio=3Dundef uselargefiles=3Ddefine =
usesocks=3Dundef
>     use64bitint=3Ddefine use64bitall=3Dundef uselongdouble=3Dundef
>     usemymalloc=3Dy, bincompat5005=3Dundef
>   Compiler:
>     cc=3D'gcc', ccflags =3D'-DPERL_USE_SAFE_PUTENV =
-fno-strict-aliasing',
>     optimize=3D'-O2',
>     cppflags=3D'-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing'
>     ccversion=3D'', gccversion=3D'3.1.1 20020718 (prerelease)',=20
> gccosandvers=3D''
>     intsize=3D4, longsize=3D4, ptrsize=3D4, doublesize=3D8, =
byteorder=3D12345678
>     d_longlong=3Ddefine, longlongsize=3D8, d_longdbl=3Ddefine, =
longdblsize=3D12
>     ivtype=3D'long long', ivsize=3D8, nvtype=3D'double', nvsize=3D8,=20=

> Off_t=3D'off_t', lseeksize=3D4
>     alignbytes=3D8, prototype=3Ddefine
>   Linker and Libraries:
>     ld=3D'ld2', ldflags =3D' -s -L/usr/local/lib'
>     libpth=3D/usr/local/lib /usr/lib /lib
>     libs=3D-lgdbm -lcrypt -lutil
>     perllibs=3D-lcrypt -lutil
>     libc=3D/usr/lib/libc.a, so=3Ddll, useshrplib=3Dtrue, =
libperl=3Dlibperl.a
>     gnulibc_version=3D''
>   Dynamic Linking:
>     dlsrc=3Ddl_dlopen.xs, dlext=3Ddll, d_dlsymun=3Dundef, ccdlflags=3D' =
-s'
>     cccdlflags=3D' ', lddlflags=3D' -s -L/usr/local/lib'
>
>

  -Ken

[Module-build-general] Re: Module::Build

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

On Wednesday, August 28, 2002, at 10:06 PM, Matthew Byng-Maddick wrote:
> I went to Hugo's london.pm talk last night, and he talked about 
> Module::Build as one of the big changes for 5.10.

Cool, I didn't know he was speaking about it.

> I've just been looking at the search.cpan.org render of 
> Build.pm's perldoc. What you don't seem to provide that would 
> certainly be useful to all sorts of people is a way of hooking 
> this to legacy packaging systems. I know that it would be 
> fantastic if I could have perl modules on my FreeBSD system 
> install as if they were just ports, or on my Debian system as 
> if they were just Debian packages.

The step I've taken in that direction is to make modules' 
meta-information become more static and more accessible.  
There's a new META.yaml file that contains the distribution 
name, version, dependencies, license, and a few other things, 
including whether this information can be considered 
"authoritative" or not (or whether the Build.PL script needs to 
be run before you get the "real" answers).

I'm hoping that this kind of information will be enough for 
someone to write a packaging layer on top.  The packaging layer 
might become part of Module::Build, but I'm guessing it might 
fit better in CPAN.pm or its replacement.

> I'm not suggesting that you write the actual code to do this, 
> but depending
> on what stage of development this module is in, if you can 
> provide hooks that allow for an OS-installed module to be able 
> to manage versions in this way, I think this would be very very 
> useful.

I definitely agree.

By the way, there's a low-volume Module::Build mailing list, 
which I'm Cc-ing on this message.

  -Ken

Re: [Module-build-general] sorting tests

[David W. <da...@wh...>]

On Tuesday, August 27, 2002, at 06:19  PM, Ken Williams wrote:

> Yeah, but I usually do it just in a "simple-to-complicated" ordering, 
> or in a "this-helps-me-remember" ordering.  I've yet to actually 
> create order dependencies between tests, at least not on purpose. =)

Same here. Dependencies are bad, but this is okay, and ultimately makes 
the ordering convenient from a conceptual point of view, but not at all 
important for the actual execution of tests.

David

-- 
David Wheeler                                     AIM: dwTheory
da...@wh...                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e
                                                Jabber: Th...@ja...

Re: [Module-build-general] sorting tests

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

On Wednesday, August 28, 2002, at 02:29 AM, David Wheeler wrote:

> On Tuesday, August 27, 2002, at 02:28  AM, Ken Williams wrote:
>
>> Yeah, I agree that TEST_FILES is handy, and some kind of 
>> selector mechanism like that should be in M::B.  Not sure what 
>> the syntax should look like yet.  Internally, it should just 
>> generate a list of files to run.
>
> While I think that this is a decent feature, I think that 
> really we should discourage people from ordering their tests. 
> In an ideal testing environment, tests won't have dependencies 
> on each other, and order shouldn't matter. The docs ought to 
> say that, IMO, and point to some decent documentation or 
> tutorial on unit testing.

Yeah, I agree.  That sounds like a reasonable approach.

IMO, the main reason for having something like TEST_FILES is so 
you can only execute a single test.  That's often a big 
time-saver when tracking down a bug.


>
> That said, I've been known to name tests so that they execute 
> in a certain order, myself. :-\

Yeah, but I usually do it just in a "simple-to-complicated" 
ordering, or in a "this-helps-me-remember" ordering.  I've yet 
to actually create order dependencies between tests, at least 
not on purpose. =)

  -Ken

Re: [Module-build-general] sorting tests

[David W. <da...@wh...>]

On Tuesday, August 27, 2002, at 02:28  AM, Ken Williams wrote:

> Yeah, I agree that TEST_FILES is handy, and some kind of selector 
> mechanism like that should be in M::B.  Not sure what the syntax 
> should look like yet.  Internally, it should just generate a list of 
> files to run.

While I think that this is a decent feature, I think that really we 
should discourage people from ordering their tests. In an ideal testing 
environment, tests won't have dependencies on each other, and order 
shouldn't matter. The docs ought to say that, IMO, and point to some 
decent documentation or tutorial on unit testing.

That said, I've been known to name tests so that they execute in a 
certain order, myself. :-\

David

-- 
David Wheeler                                     AIM: dwTheory
da...@wh...                                 ICQ: 15726394
http://david.wheeler.net/                      Yahoo!: dew7e
                                                Jabber: Th...@ja...

Re: [Module-build-general] sorting tests

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

On Monday, August 26, 2002, at 02:00  AM, Dave Rolsky wrote:
> By default, tests are now sorted in ExtUtils::MakeMaker.  In older
> versions, it just used 'glob', which normally sorted the results anyway.

I sort of wish Test::Harness sorted these internally, instead of 
requiring the caller to sort them.  But I can do a patch like this, in 
any case, until it's deemed inadequate:

=======================================
    if (@tests) {
      # Work around a Test::Harness bug that loses the particular perl 
we're running under
      local $^X = $self->{config}{perlpath} unless 
$Test::Harness::VERSION gt '2.01';
-    Test::Harness::runtests(@tests);
+    Test::Harness::runtests(sort @tests);
    } else {
      print("No tests defined.\n");
    }
=======================================

I'll apply it when Sourceforge imports the CVS tree.


>
> There is also a 'TEST_FILES' parameter for WriteMakefile which 
> specifies a
> list of tests to run (I think as a string).  It'd be good to have an
> equivalent for M::B.

Yeah, I agree that TEST_FILES is handy, and some kind of selector 
mechanism like that should be in M::B.  Not sure what the syntax should 
look like yet.  Internally, it should just generate a list of files to 
run.

  -Ken

[Module-build-general] sorting tests

[Dave R. <au...@ur...>]

By default, tests are now sorted in ExtUtils::MakeMaker.  In older
versions, it just used 'glob', which normally sorted the results anyway.

There is also a 'TEST_FILES' parameter for WriteMakefile which specifies a
list of tests to run (I think as a string).  It'd be good to have an
equivalent for M::B.  But just sorting is important because of all the
01_foo, 02_bar tests out there.


-dave

/*==================
www.urth.org
we await the New Sun
==================*/

[Module-build-general] verbose and Test::Harness

[Dave R. <au...@ur...>]

There's a number of different versions of Test::Harness out there, and at
least with the one installed on my system (2.24), "Build test verbose=1"
does not actually lead to verbose output.  This patch fixes that while
still preserving the old code, which presumably works with some versions
of Test::Harness.

This also does the same thing for test 'switches', on the theory that it
can't hurt.  I'm not really sure how to test this.


-dave


diff -wru ../Module-Build-0.11/lib/Module/Build/Base.pm ./lib/Module/Build/Base.pm
--- ../Module-Build-0.11/lib/Module/Build/Base.pm	2002-08-24 00:58:27.000000000 +0800
+++ ./lib/Module/Build/Base.pm	2002-08-24 01:08:10.000000000 +0800
@@ -563,9 +563,16 @@

   $self->depends_on('build');

-  local $Test::Harness::switches = '-w -d' if $self->{properties}{debugger};
-  local $Test::Harness::verbose = $self->{properties}{verbose} || 0;
-  local $ENV{TEST_VERBOSE} = $self->{properties}{verbose} || 0;
+  local ($Test::Harness::switches,
+         $Test::Harness::Switches,
+         $ENV{HARNESS_PERL_SWITCHES}) = ('-w -d') x 2
+             if $self->{properties}{debugger};
+
+  my $verbose = $self->{properties}{verbose} || 0;
+
+  local ($Test::Harness::verbose,
+         $Test::Harness::Verbose,
+         $ENV{TEST_VERBOSE},
+         $ENV{HARNESS_VERBOSE}) = ($verbose) x 4;

   # Make sure we test the module in blib/
   {

[Module-build-general] ANNOUNCE: Module::Build 0.11 -> CPAN

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

Hi,

The uploaded file

     Module-Build-0.11.tar.gz

has entered CPAN as

   file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.11.tar.gz
   size: 35612 bytes
    md5: ac67c0f907e1839eee819afa7a027972

Changes since 0.10:


   - 'module_version' and 'module_version_from' have been replaced by
     'dist_version' and 'dist_version_from', which is what they really
     meant in the first place.  'dist_name' has been added.

   - 'module_name' is now just a way to set 'dist_name' and
     'dist_version_from' in a convenient way.

   - The 'name' in META.yaml is now the distribution name, not the
     (incorrect) module name. [spotted by Graham Barr]

   - Added the check_installed_status() and prereq_failures() methods
     for checking prerequisite information with the programmatic
     interface

   - check_installed_version() now uses check_installed_status()
     internally

   - Documented the create_build_script() method, which had escaped
     documentation.

   - create_build_script() now writes prerequisite information to the
     _build/ directory, for use by Module::Build::Compat.

   - Module::Build::Compat has documentation for a safer way to write a
     dummy Makefile.PL [patch by Autrijus Tang].


  -Ken

Re: [Module-build-general] [PATCH] Make Compat.pm play well with old CPAN(PLUS)?.pm.

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

On Friday, August 16, 2002, at 05:30 PM, Ken Williams wrote:

>
> On Thursday, August 15, 2002, at 08:57 PM, Autrijus Tang wrote:
>> As attached.  Two things are fixed:
>>
>> - PREREQ_PM info is now written to Makefile.
>> - Friendly bootstrapping code that makes Module::Build to
>>   be installed first.
>
> Both good goals.
>

Here's the patch in the form I'm applying it.  It uses a new 
_build/prereq file to get the valid prereq information.

  -Ken

===================================================================
RCS file: /Users/ken/src/CVS-repository/modules/Module-
Build/lib/Module/Build/Compat.pm,v
retrieving revision 1.4
diff -u -r1.4 Compat.pm
--- Compat.pm	2002/08/11 10:14:09	1.4
+++ Compat.pm	2002/08/19 09:20:07
@@ -1,7 +1,7 @@
-# $Id $

  package Module::Build::Compat;
  use strict;
+use File::Spec;

  my %makefile_to_build =
    (
@@ -40,12 +40,32 @@
  EOF
  }

+sub fake_prereqs {
+  my $file = File::Spec->catfile('_build', 'prereqs');
+  open my $fh, "< $file" or die "Can't read $file: $!";
+  my $prereqs = eval do {local $/; <$fh>};
+  close $fh;
+
+  my @prereq;
+  foreach my $section (qw/build_requires requires recommends/) {
+    foreach (keys %{$prereqs->{$section}}) {
+      next if $_ eq 'perl';
+      push @prereq, "$_=>q[$prereqs->{$section}{$_}]";
+    }
+  }
+
+  return unless @prereq;
+  return "#     PREREQ_PM => { " . join(", ", @prereq) . " }\n\n";
+}
+
+
  sub write_makefile {
    # Note - this doesn't yet emulate the PREREQ_PM stuff.

    my ($pack, %in) = @_;
    $in{makefile} ||= 'Makefile';
    open  MAKE, "> $in{makefile}" or die "Cannot write 
$in{makefile}: $!";
+  print MAKE $pack->fake_prereqs;
    print MAKE $pack->fake_makefile($in{makefile});
    close MAKE;
  }
@@ -59,12 +79,29 @@
  Module::Build::Compat - Compatibility with ExtUtils::MakeMaker

  =head1 SYNOPSIS
+
+Here's a Makefile.PL that passes all functionality through to 
Module::Build

- Here's a Makefile.PL that passes all functionality through to 
Module::Build
-
    use Module::Build::Compat;
    Module::Build::Compat->run_build_pl(args => \@ARGV);
    Module::Build::Compat->write_makefile();
+
+
+Or, here's one that's more careful about sensing whether Module::Build
+is already installed:
+
+  unless (eval { require Module::Build::Compat; 1 }) {
+    # Workaround with old CPAN.pm and CPANPLUS.pm
+    require ExtUtils::MakeMaker;
+    ExtUtils::MakeMaker::WriteMakefile(
+      PREREQ_PM => { 'Module::Build::Compat' => 0 }
+    );
+    warn "Warning: prerequisite Module::Build::Compat is not found.\n";
+    exit(0);
+  }
+  Module::Build::Compat->run_build_pl(args => \@ARGV);
+  Module::Build::Compat->write_makefile();
+

  =head1 DESCRIPTION

Re: [Module-build-general] Re: Inline and the 5.6.0 that comes with OS X

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

On Sunday, August 18, 2002, at 11:13 PM, Dave Rolsky wrote:

> On Sun, 18 Aug 2002, Piers Harding wrote:
>
>> Another question - is it possible to get the Build.PL file to
>> sufficiently emulate a Makefile.PL file so that -
>> (a) if someone doesn't have Module::Build they get informed of it
>> and
>> (b) CPAN.pm can work with it?  ie. rename the Build.PL to 
>> Makefile.PL -
>> and it just works.  That might be a goal to aim for, as people who are
>> not familiar/interested in module build processes use tools 
>> like CPAN.pm
>> and ppms.
>
> I created a very simple Makefile a while back that could be 
> written by a
> Makefile.PL (which also called Build.PL) that simply passed everything
> through to './build'.  I don't know how cross-platform 
> compatible it was,
> but I could surely dig it up for testing.
>

No need to dig it up - that's now been incorporated into the 
main distribution (which I swear, I should get out in the next 
couple days) as a "pass-through" Makefile.PL.

  -Ken

Re: [Module-build-general] Re: Inline and the 5.6.0 that comes with OS X

[Dave R. <au...@ur...>]

On Sun, 18 Aug 2002, Piers Harding wrote:

> Another question - is it possible to get the Build.PL file to
> sufficiently emulate a Makefile.PL file so that -
> (a) if someone doesn't have Module::Build they get informed of it
> and
> (b) CPAN.pm can work with it?  ie. rename the Build.PL to Makefile.PL -
> and it just works.  That might be a goal to aim for, as people who are
> not familiar/interested in module build processes use tools like CPAN.pm
> and ppms.

I created a very simple Makefile a while back that could be written by a
Makefile.PL (which also called Build.PL) that simply passed everything
through to './build'.  I don't know how cross-platform compatible it was,
but I could surely dig it up for testing.


-dave

[Module-build-general] Re: Inline and the 5.6.0 that comes with OS X

[Piers H. <pi...@om...>]

Cool.

Brian did talk about wanting to remove make from the build process - he 
was probably refering to his conversations with you.  I must admit that
I didn't think it was a good idea at the time, but perhaps it would work
if there is sufficient other ways ( that are part of the core ) to get
rid of the OS specific parst that make and MakeMaker deals with.

Another question - is it possible to get the Build.PL file to
sufficiently emulate a Makefile.PL file so that -
(a) if someone doesn't have Module::Build they get informed of it 
and
(b) CPAN.pm can work with it?  ie. rename the Build.PL to Makefile.PL -
and it just works.  That might be a goal to aim for, as people who are
not familiar/interested in module build processes use tools like CPAN.pm
and ppms.

I have Linux, and HP-UX, Windows ( of all sorts of nasty flavours ;-),
and maybe some more via Melbourne.pm if I can ask them the favour.
 
Cheers.



On Sun, Aug 18, 2002 at 07:15:55PM +1000, Ken Williams wrote:
> [Adding the Module::Build list to recipient list, and getting 
> rid of Mac OS X...]
> 
> On Sunday, August 18, 2002, at 06:11 PM, Piers Harding wrote:
> > How would Inline/Module::Build take care of ( in a platform independent
> > way ) processes like moving files, copying etc.  Would it still use the
> > ExtUtils::Command routines for this?
> 
> In general Module::Build uses lots of ExtUtils::* or File::* 
> routines.  I haven't yet seen the need for ExtUtils::Command in 
> Module::Build, because most of the things supported there either 
> have equivalents in File::* or in core perl.
> 
> 
> > It is dealing with these kinds of issues that are also dealt 
> > with in "make" that need to be overcome.  Would there be any 
> > benefit in producing a quick bunch of basic build tests that we 
> > could run on a variety of platforms to determine if this kind 
> > of approach is going to pay off.  I can help with that if it 
> > seems like a good idea?
> 
> Yes, these kinds of tests can simply become part of the 
> regression test suite for Module::Build.  It would be great to 
> add to its existing tests.
> 
> 
> > What kinds of platforms do people on the list have at their 
> > disposal for testing out these issues?
> 
> I only have Mac OS X (perl 5.6.1) at my immediate disposal, 
> though I can test on Linux (perl 5.6.1) from time to time.
> 
> In general, eliminating 'make' and using the ExtUtils::* and 
> File::* modules seem to be doing a really good job of allowing a 
> single code base with no "if ($platform eq _something_) {" 
> statements in Module::Build.
> 
>   -Ken
> 
> >
> >
> > On Sun, Aug 18, 2002 at 02:31:52PM +1000, Ken Williams wrote:
> >>
> >> On Saturday, August 17, 2002, at 08:23 AM, Nicholas Clark wrote:
> >>> Inline only uses MakeMaker to compile 1 XS file into 1 C file
> >>> into 1 shared
> >>> object, doesn't it? It's not using most of MakeMaker's functionality.
> >>
> >> This is the same subset of MakeMaker's functionality that is
> >> currently supported by Module::Build, too.
> >>
> >> The main reason Module::Build hasn't gone further is that I
> >> don't yet understand the other scenarios that need to be
> >> supported.  I can see basically what MakeMaker is capable of
> >> from its documentation, but I don't yet know how it's used in
> >> practice in CPAN modules.
> >>
> >>> Invoking the compiler in a more direct fashion would also avoid make.
> >>> So it would allow much better error diagnostics.
> >>
> >> Yeah, this is the approach Module::Build takes.  There's a
> >> compile_c() method and a link_c() method, which invoke C
> >> compilers by calling the do_system() method, which just calls
> >> CORE::system().  The compilation commands are just pieced
> >> together from pieces of the %Config hash.  I've been surprised
> >> at how successful that's been, actually.
> >>
> >>
> >> Then, on Saturday, August 17, 2002, at 04:29 PM, Brian Ingerson wrote:
> >>> I've removed the dependency of Parse::RecDescent thanks to a
> >>> great patch from
> >>> Mitchell Charity that does the job with regexps. It'd be a
> >>> shame to add a new
> >>> dependency.
> >>
> >> If you don't want another dependency for Inline itself, you
> >> could certainly copy the compile_c() and link_c() methods from
> >> Module::Build.  They're fairly simple.  It would be nice to
> >> share some code, though, for the reasons Nick outlined.
> >>
> >>> It would be cool to distribute M::B within Inline and also within
> >>> the modules that require Inline.
> >>
> >> This doesn't really help, I think.  It's not that people are too
> >> lazy to download the prerequisites, it's that they don't want
> >> the conceptual complexity of a larger (and seemingly
> >> unnecessary - see below) web of installed prerequisites on their
> >> system.
> >>
> >>> The ultimate goal being that you want
> >>> authors to be able to use Inline instead of XS without it 
> >>> imposing any
> >>> dependencies on their work. I think this is one thing that
> >>> keeps people from
> >>> writing serious modules with Inline.
> >>
> >> I think that if Inline were truly a build-time-only dependency
> >> for modules (without even the small run-time stub you've been
> >> thinking of), that would help quite a bit.  I don't think people
> >> care so much about startup performance as they do keeping track
> >> of prerequisites.  Module::Build introduces the concept of
> >> build_requires vs. requires, maybe this would help.
> >>
> >> If Inline weren't a run-time dependency, then, you could feel
> >> free to have Inline depend on whatever you wanted.  You wouldn't
> >> be saddling people's modules with more dependencies.
> >>
> >>   -Ken

[Module-build-general] Re: Inline and the 5.6.0 that comes with OS X

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

[Adding the Module::Build list to recipient list, and getting 
rid of Mac OS X...]

On Sunday, August 18, 2002, at 06:11 PM, Piers Harding wrote:
> How would Inline/Module::Build take care of ( in a platform independent
> way ) processes like moving files, copying etc.  Would it still use the
> ExtUtils::Command routines for this?

In general Module::Build uses lots of ExtUtils::* or File::* 
routines.  I haven't yet seen the need for ExtUtils::Command in 
Module::Build, because most of the things supported there either 
have equivalents in File::* or in core perl.


> It is dealing with these kinds of issues that are also dealt 
> with in "make" that need to be overcome.  Would there be any 
> benefit in producing a quick bunch of basic build tests that we 
> could run on a variety of platforms to determine if this kind 
> of approach is going to pay off.  I can help with that if it 
> seems like a good idea?

Yes, these kinds of tests can simply become part of the 
regression test suite for Module::Build.  It would be great to 
add to its existing tests.


> What kinds of platforms do people on the list have at their 
> disposal for testing out these issues?

I only have Mac OS X (perl 5.6.1) at my immediate disposal, 
though I can test on Linux (perl 5.6.1) from time to time.

In general, eliminating 'make' and using the ExtUtils::* and 
File::* modules seem to be doing a really good job of allowing a 
single code base with no "if ($platform eq _something_) {" 
statements in Module::Build.

  -Ken

>
>
> On Sun, Aug 18, 2002 at 02:31:52PM +1000, Ken Williams wrote:
>>
>> On Saturday, August 17, 2002, at 08:23 AM, Nicholas Clark wrote:
>>> Inline only uses MakeMaker to compile 1 XS file into 1 C file
>>> into 1 shared
>>> object, doesn't it? It's not using most of MakeMaker's functionality.
>>
>> This is the same subset of MakeMaker's functionality that is
>> currently supported by Module::Build, too.
>>
>> The main reason Module::Build hasn't gone further is that I
>> don't yet understand the other scenarios that need to be
>> supported.  I can see basically what MakeMaker is capable of
>> from its documentation, but I don't yet know how it's used in
>> practice in CPAN modules.
>>
>>> Invoking the compiler in a more direct fashion would also avoid make.
>>> So it would allow much better error diagnostics.
>>
>> Yeah, this is the approach Module::Build takes.  There's a
>> compile_c() method and a link_c() method, which invoke C
>> compilers by calling the do_system() method, which just calls
>> CORE::system().  The compilation commands are just pieced
>> together from pieces of the %Config hash.  I've been surprised
>> at how successful that's been, actually.
>>
>>
>> Then, on Saturday, August 17, 2002, at 04:29 PM, Brian Ingerson wrote:
>>> I've removed the dependency of Parse::RecDescent thanks to a
>>> great patch from
>>> Mitchell Charity that does the job with regexps. It'd be a
>>> shame to add a new
>>> dependency.
>>
>> If you don't want another dependency for Inline itself, you
>> could certainly copy the compile_c() and link_c() methods from
>> Module::Build.  They're fairly simple.  It would be nice to
>> share some code, though, for the reasons Nick outlined.
>>
>>> It would be cool to distribute M::B within Inline and also within
>>> the modules that require Inline.
>>
>> This doesn't really help, I think.  It's not that people are too
>> lazy to download the prerequisites, it's that they don't want
>> the conceptual complexity of a larger (and seemingly
>> unnecessary - see below) web of installed prerequisites on their
>> system.
>>
>>> The ultimate goal being that you want
>>> authors to be able to use Inline instead of XS without it 
>>> imposing any
>>> dependencies on their work. I think this is one thing that
>>> keeps people from
>>> writing serious modules with Inline.
>>
>> I think that if Inline were truly a build-time-only dependency
>> for modules (without even the small run-time stub you've been
>> thinking of), that would help quite a bit.  I don't think people
>> care so much about startup performance as they do keeping track
>> of prerequisites.  Module::Build introduces the concept of
>> build_requires vs. requires, maybe this would help.
>>
>> If Inline weren't a run-time dependency, then, you could feel
>> free to have Inline depend on whatever you wanted.  You wouldn't
>> be saddling people's modules with more dependencies.
>>
>>   -Ken

Re: [Module-build-general] [PATCH] Make Compat.pm play well with old CPAN(PLUS)?.pm.

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

On Thursday, August 15, 2002, at 08:57 PM, Autrijus Tang wrote:
> As attached.  Two things are fixed:
>
> - PREREQ_PM info is now written to Makefile.
> - Friendly bootstrapping code that makes Module::Build to
>   be installed first.

Both good goals.


> I hadn't tested extensively whether old CPAN.pm will resume
> from 'perl Makefile.PL' step or merely 'make'.  If it's
> the latter case then we also need a fake 'all :' target
> that runs 'Build.PL' again in the POD.

A shame that this all has to be in the POD instead of just in 
the module.  I suppose we could create a little utility method 
that writes out one of these dummy Makefile.PL thingies for the 
author.



>
> -sub write_makefile {
> -  # Note - this doesn't yet emulate the PREREQ_PM stuff.
> +sub fake_prereqs {
> +  my ($pack, %in) = @_;
> +  $in{metadata} ||= 'META.yaml';

Unfortunately it's not quite right to read the META.yaml file 
after you run Build.PL, because the answers might have changed 
(for example, if Build.PL asks the users some questions, or 
senses its environment, to determine the prereqs).  Build.PL 
doesn't update the META.yaml file, because the user might not 
have YAML installed - and that file isn't supposed to change 
from one user's machine to another, either.

I think what's required is for the create_build_script() method 
to write a file, say _build/prereq, that can be read later.


> +    while (<META>) {
> +      next if (1 .. /^$section:$/);

Nice flip-flop. =)

  -Ken

[Module-build-general] [PATCH] Make Compat.pm play well with old CPAN(PLUS)?.pm.

[Autrijus T. <aut...@au...>]

As attached.  Two things are fixed:

- PREREQ_PM info is now written to Makefile.
- Friendly bootstrapping code that makes Module::Build to
  be installed first.

I hadn't tested extensively whether old CPAN.pm will resume
from 'perl Makefile.PL' step or merely 'make'.  If it's
the latter case then we also need a fake 'all :' target
that runs 'Build.PL' again in the POD.

Thanks,
/Autrijus/

--- lib/Module/Build/Compat.pm	Wed Jun  5 11:25:43 2002
+++ /home/autrijus/Compat.pm	Thu Aug 15 18:52:39 2002
@@ -36,12 +36,31 @@
 EOF
 }
 
-sub write_makefile {
-  # Note - this doesn't yet emulate the PREREQ_PM stuff.
+sub fake_prereqs {
+  my ($pack, %in) = @_;
+  $in{metadata} ||= 'META.yaml';
+
+  my @prereq;
+  foreach my $section (qw/build_requires requires/) {
+    # parse YAML's prerequisite info
+    open META, $in{metadata} or die "Cannot read $in{metadata}: $!";
+    while (<META>) {
+      next if (1 .. /^$section:$/);
+      last unless /^  (.*): (.*)$/;
+      push @prereq, "$1=>q[$2]" unless $1 eq 'perl';
+    }
+    close META;
+  }
 
+  return unless @prereq;
+  return "#     PREREQ_PM => { " . join(", ", @prereq) . " }\n\n";
+}
+
+sub write_makefile {
   my ($pack, %in) = @_;
   $in{makefile} ||= 'Makefile';
   open  MAKE, "> $in{makefile}" or die "Cannot write $in{makefile}: $!";
+  print MAKE $pack->fake_prereqs;
   print MAKE $pack->fake_makefile;
   close MAKE;
 }
@@ -58,7 +77,16 @@
 
  Here's a Makefile.PL that passes all functionality through to Module::Build
  
-  use Module::Build::Compat;
+  unless (eval { require Module::Build::Compat; 1 }) {
+      # Workaround with old CPAN.pm and CPANPLUS.pm
+      require ExtUtils::MakeMaker;
+      ExtUtils::MakeMaker::WriteMakefile(
+	  'PREREQ_PM' => { 'Module::Build::Compat' => 0 }
+      );
+      warn "Warning: prerequisite Module::Build::Compat is not found.\n";
+      exit(0);
+  }
+
   Module::Build::Compat->run_build_pl(args => \@ARGV);
   Module::Build::Compat->write_makefile();
 

Re: [Module-build-general] Re: META.yaml in Module-Build dist

[Graham B. <gb...@po...>]

On Wed, Aug 14, 2002 at 09:43:10PM +1000, Ken Williams wrote:
> > Also read your docs. The autosplit call. Why do you need it ?
> > MM does a scan of each .pm for /^use AutoSplit/ to determine
> > which need splitting.
> 
> I can't actually find that in the MM source, can you point me to it?
> 
> I know it was happening *somehow* automatically, though.  Part 
> of the reason I changed it was that I didn't like the magical 
> scanning of code in MM.  I think the scanning for $VERSION is 
> unfortunately quite necessary, but I'd like for that to be the 
> only code scanning if possible.

Actually it does not look for use AutoSplit. ExtUtils::Install calls
autosplit() on _every_ .pm file as it installs it into blib. autosplit()
will check for use AutoLoader

Graham.

Re: [Module-build-general] Re: META.yaml in Module-Build dist

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

On Wednesday, August 14, 2002, at 08:43 PM, Graham Barr wrote:
> After sending this I started to compare with what MM does.
>
> With MM you pass NAME and VERSION or VERSION_FROM. Where NAME
> is a module name. You can optionally pass DISTNAME
>
> and DISTNAME defaults to NAME =~ s/::/-/g
>
> So maybe all that sneeded is for another method + yaml entry
> for distname.

Yeah, that's close to what I'm thinking.  Here's my current proposal:

  1) Replace module_version and module_version_from parameters 
with dist_version and dist_version_from.  They really were facts 
about the distribution anyway, but I didn't realize it.

  2) Create a dist_name parameter which is essentially the same 
as MakeMaker's NAME parameter.

  3) Make module_name into a shortcut for setting dist_name and 
dist_version_from in one go.  This handles the most common case 
nicely, in which a distribution houses a single "chief" module.

I don't think I have a problem with the backward-compatibility 
breakage of 1).  2) and 3) don't have any such problems.


> Also read your docs. The autosplit call. Why do you need it ?
> MM does a scan of each .pm for /^use AutoSplit/ to determine
> which need splitting.

I can't actually find that in the MM source, can you point me to it?

I know it was happening *somehow* automatically, though.  Part 
of the reason I changed it was that I didn't like the magical 
scanning of code in MM.  I think the scanning for $VERSION is 
unfortunately quite necessary, but I'd like for that to be the 
only code scanning if possible.

  -Ken

[Module-build-general] Re: META.yaml in Module-Build dist

[Graham B. <gb...@po...>]

After sending this I started to compare with what MM does.

With MM you pass NAME and VERSION or VERSION_FROM. Where NAME
is a module name. You can optionally pass DISTNAME

and DISTNAME defaults to NAME =~ s/::/-/g

So maybe all that sneeded is for another method + yaml entry
for distname.

Also read your docs. The autosplit call. Why do you need it ?
MM does a scan of each .pm for /^use AutoSplit/ to determine
which need splitting.

Graham.

On Wed, Aug 14, 2002 at 10:30:26AM +1000, Ken Williams wrote:
> Hi Graham,
> 
> You're right, I'll change the name to the distribution name.  
> Regarding the version, it should be settable in the Build.PL if 
> it doesn't come from a module, just like in MakeMaker.  Is there 
> something that needs fixing there?  Perhaps the 'module_name', 
> 'module_version', and 'module_version_from' parameters are 
> misnamed in the new() method, since they (should) really refer 
> to the distribution, not a module.  Is this what you mean?
> 
> Thanks for the suggestions.
> 
>   -Ken
> 
> On Wednesday, August 14, 2002, at 12:44 AM, Graham Barr wrote:
> 
> > Ken,
> >
> > I am looking forward to having a meta file in distributions so
> > that search can start using it. However I was reading the fail
> > in the Module-Build distribution. It contains the line
> >
> > name: Module::Build
> >
> > I would suggest that this is wrong. A distribution is not one module
> > and the meta file should be about the distribution. IMO that line
> > should be
> >
> > name: Module-Build
> >
> > consider distributions like libnet, libwww-perl or any other
> > distribution that contains many modules.
> >
> > The same goes for the version. In these distribution that
> > have many modules, the version of the distribution is
> > not always extracted from one of the modules.
> >
> > Graham.
> 

Re: [Module-build-general] Re: Cryptographically signing distros

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

On Monday, August 12, 2002, at 05:17 PM, Andreas J. Koenig wrote:
>
> No, what I meant was (1) each file needs a digest (=checksum) and (2)
> the table needs to be signed that lists all files and all digests.
> This is in contrast to the widely established practice to first
> tar+gzip the distribution and then sign it. Advantages: 50% less files
> out there on servers, later verification OK, repackaging OK,
> re-compressing OK.

The only disadvantage I can think of is that you have to unpack 
the distro before you know whether its signature is valid.  This 
might just be inconvenient, or it might be dangerous: a 
malicious tarball could contain a file like /bin/ls, which would 
suck if you weren't careful about untarring.

> META.yaml might be a good place to put the digests in and then 
> let the people sign that. You just need to be aware that the 
> file that contains the signature cannot have a checksum itself. 
> Thus it acts as a seal to the distribution.

That would probably be too much stuff to stick in META.yaml, I 
think.  How about creating a separate DIGESTS (or CHECKSUMS) 
file that lists checksums for all the files in MANIFEST, and 
then a META.yaml field called "signature" or "pgp_signature" or 
something, which is a signature of DIGESTS?

Actually, is the DIGESTS file even needed?  Couldn't the author 
just sign all the distro data as one big chunk, in the order 
each file appears in MANIFEST, and add that signature as a field 
in META.yaml?

  -Ken

[Module-build-general] Re: META.yaml in Module-Build dist

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

Hi Graham,

You're right, I'll change the name to the distribution name.  
Regarding the version, it should be settable in the Build.PL if 
it doesn't come from a module, just like in MakeMaker.  Is there 
something that needs fixing there?  Perhaps the 'module_name', 
'module_version', and 'module_version_from' parameters are 
misnamed in the new() method, since they (should) really refer 
to the distribution, not a module.  Is this what you mean?

Thanks for the suggestions.

  -Ken

On Wednesday, August 14, 2002, at 12:44 AM, Graham Barr wrote:

> Ken,
>
> I am looking forward to having a meta file in distributions so
> that search can start using it. However I was reading the fail
> in the Module-Build distribution. It contains the line
>
> name: Module::Build
>
> I would suggest that this is wrong. A distribution is not one module
> and the meta file should be about the distribution. IMO that line
> should be
>
> name: Module-Build
>
> consider distributions like libnet, libwww-perl or any other
> distribution that contains many modules.
>
> The same goes for the version. In these distribution that
> have many modules, the version of the distribution is
> not always extracted from one of the modules.
>
> Graham.

[Module-build-general] Re: Cryptographically signing distros

[<and...@an...>]

>>>>> On Mon, 12 Aug 2002 16:29:43 +1000, Ken Williams <ke...@ma...> said:

  > Hi,
  > Andreas posted this message recently on p5p, it's relevant to
  > Module::Build so I'm forwarding to the list.  I admit to not knowing
  > too much about the matter, but I agree that something should be added.

  > It might be appropriate to include a digest as an item in the
  > generated META.yaml file.  Andreas, would this fulfill the
  > requirements you can think of?  You seem to indicate that each file in
  > the distro needs to be signed independently - why is that?  Do people
  > really need that kind of fine-grained signing?

No, what I meant was (1) each file needs a digest (=checksum) and (2)
the table needs to be signed that lists all files and all digests.
This is in contrast to the widely established practice to first
tar+gzip the distribution and then sign it. Advantages: 50% less files
out there on servers, later verification OK, repackaging OK,
re-compressing OK.

META.yaml might be a good place to put the digests in and then let the
people sign that. You just need to be aware that the file that
contains the signature cannot have a checksum itself. Thus it acts as
a seal to the distribution.

-- 
andreas