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

[Module-build-general] scripts inconsistency with EU:MM

[Richard C. <ric...@un...>]

I've discovered an inconsistency between Module::Build and EU::MM.

When I declare a script via the scripts property Module::Build isn't
rewriting the shebang line to match that of the perl it's installing
against, so when I later run the script it fails in the require of
it's companion module.

MakeMaker uses ExtUtils::MM->fixin($script) to do it, if that helps any.

-- 
Richard Clamp <ric...@un...>

Re: [Module-build-general] Question about Defaults ...

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

On Sat, 15 Mar 2003, Randy W. Sims wrote:

> This brings to mind a problem I've run into: What about CPAN authors who
> want to provide both Makefile.PL and Build.PL during the transition for
> backwards compatibility? When I try this Makefile.PL wants execute
> Build.PL as a self-extracting script. Maybe this has come up before, but
> I couldn't find any references.
>
> Two options that immediately come to mind are:
>
> * Require that the PL_FILES option be specified in the Makefile.PL even
> if it is an empty array so that MM doesn't perform its auto search for
> PL files.
>
> * Add something like the following to the top Build.PL:
> BEGIN { # Don't let it MakeMaker extract me && substitute my variables.
>    exit if @ARGV == 1 && $ARGV[0] eq 'Build';
> }
>
> What is the best way to handle this scenario? I'm currently using the
> second. Although its a hack, it feels like a better solution than
> requiring authors to change their existing Makefile.PL to explicitly
> mention every PL file.

Have you looked at the docs for Module::Build::Compat?  It has an example
Makefile.PL that simply passes through everything to Build.PL, and it even
can install Module::Build for you if it's not already installed.  I've
used it with at least one module on CPAN, Thesaurus, and it works quite
well.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

Re: [Module-build-general] Question about Defaults ...

[Randy W. S. <Ra...@Th...>]

On 3/14/2003 6:09 PM, Nicholas Clark wrote:
> On Fri, Mar 14, 2003 at 12:45:17PM -0600, Dave Rolsky wrote:
> 
>>h2xs for module creation needs to die along with MakeMaker ;)
> 
> 
> and xsubpp (being worked on, IIRC) etc
> 
> h2xs isn't going to die in 5.8.1
> But I suspect that there's still time to get a patch for 5.8.1 in to add an
> option to h2xs to make the module use Module::Build rather than MakeMaker
> 
> Nicholas Clark
> 

This brings to mind a problem I've run into: What about CPAN authors who 
want to provide both Makefile.PL and Build.PL during the transition for 
backwards compatibility? When I try this Makefile.PL wants execute 
Build.PL as a self-extracting script. Maybe this has come up before, but 
I couldn't find any references.

Two options that immediately come to mind are:

* Require that the PL_FILES option be specified in the Makefile.PL even 
if it is an empty array so that MM doesn't perform its auto search for 
PL files.

* Add something like the following to the top Build.PL:
BEGIN { # Don't let it MakeMaker extract me && substitute my variables.
   exit if @ARGV == 1 && $ARGV[0] eq 'Build';
}

What is the best way to handle this scenario? I'm currently using the 
second. Although its a hack, it feels like a better solution than 
requiring authors to change their existing Makefile.PL to explicitly 
mention every PL file.

Randy.

-- 
A little learning is a dang'rous thing;
Drink deep, or taste not the Pierian spring;
There shallow draughts intoxicate the brain;
And drinking largely sobers us again.
                 - Alexander Pope

[Module-build-general] EU::ModuleMaker patch

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

Hi, Geoff, this patch adds support for Module::Build to EU::MM.  Also, I'd
like to suggest a new name for the module.  The ExtUtils prefix is really
for code designed to interface with external (non-Perl) utilities, like
make or compilers.

I think a better name would be Module::Maker or something like that.
Also, you should talk to Hugo about putting this module in the core as a
replacement for using h2xs for the same thing, because h2xs is not the
right tool for this job.

The patch is below my sig.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/


diff -ur ../ExtUtils-ModuleMaker-0.31229/lib/ExtUtils/ModuleMaker.pm ./lib/ExtUtils/ModuleMaker.pm
--- ../ExtUtils-ModuleMaker-0.31229/lib/ExtUtils/ModuleMaker.pm	2003-02-15 12:08:26.000000000 -0600
+++ ./lib/ExtUtils/ModuleMaker.pm	2003-03-15 03:25:13.000000000 -0600
@@ -112,8 +112,7 @@

 =item ABSTRACT

-A short description of the module, this will be passed on to MakeMaker through Makefile.PL.
-CPAN likes to use this feature to describe the module.
+A short description of the module.  CPAN likes to use this feature to describe the module.

 =item VERSION

@@ -132,6 +131,17 @@

 Some licenses include placeholders that will be replaced with AUTHOR information.

+=item BUILD_SYSTEM
+
+This can take one of three values.  These are 'ExtUtils::MakeMaker',
+'Module::Build', and 'Module::Build and Proxy'.  The first generates a
+basic Makefile.PL file for your module.  The second creates a Build.PL
+file, and the last creates a Build.PL along with a proxy Makefile.PL
+script that attempts to install Module::Build if necessary, and then
+runs the Build.PL script.  This option is recommended if you want to
+use Module::Build as your build system.  See Module::Build::Compat for
+more details.
+
 =item AUTHOR

 A hash containing information about the author to pass on to all the
@@ -271,6 +281,7 @@
 						EMAIL			=> 'a.u.thor@a.galaxy.far.far.away',
 						NAME			=> 'A. U. Thor',
 					   },
+                                        BUILD_SYSTEM                    => 'ExtUtils::MakeMaker',
 					COMPACT				=> 0,
 					VERBOSE				=> 0,
 					INTERACTIVE			=> 0,
@@ -361,7 +372,15 @@
 	}

 	#Makefile must be created after generate_pm_file which sets $self->{FILE}
-	$self->print_file ('Makefile.PL',	$self->FileText_Makefile ());
+        if ($self->{BUILD_SYSTEM} eq 'ExtUtils::MakeMaker') {
+	        $self->print_file ('Makefile.PL', $self->FileText_Makefile ());
+	} else {
+	        $self->print_file ('Build.PL', $self->FileText_Buildfile ());
+		if ($self->{BUILD_SYSTEM} eq 'Module::Build and proxy Makefile.PL') {
+		        $self->print_file ('Makefile.PL', $self->FileText_Proxy_Makefile ());
+		}
+	}
+
 	$self->print_file ('MANIFEST', join ("\n", @{$self->{MANIFEST}}));
 }

@@ -417,13 +436,13 @@

 =head2 sample_function

- Usage     : How to use this function/method
+ Usage	   : How to use this function/method
  Purpose   : What it does
  Returns   : What it returns
  Argument  : What it wants to know
- Throws    : Exceptions and other anomolies
+ Throws	   : Exceptions and other anomolies
  Comments  : This is a sample subroutine header.
-           : It is polite to include more pod and fewer comments.
+	   : It is polite to include more pod and fewer comments.

 See Also   :

@@ -459,14 +478,14 @@

 =head2 Create_Base_Directory

- Usage     :
+ Usage	   :
  Purpose   :
-             Create the directory where all the files will be created.
+	     Create the directory where all the files will be created.
  Returns   :
-             $DIR = directory name where the files will live
+	     $DIR = directory name where the files will live
  Argument  :
-             $package_name = name of module separated by '::'
- Throws    :
+	     $package_name = name of module separated by '::'
+ Throws	   :
  Comments  :

 See Also   : Check_Dir
@@ -962,6 +981,23 @@
 {
 	my ($self) = @_;

+my $build_instructions;
+if ($self->{BUILD_SYSTEM} eq 'ExtUtils::MakeMaker') {
+$build_instructions = <<EOF;
+perl Makefile.PL
+make
+make test
+make install
+EOF
+} else {
+$build_instructions = <<EOF;
+perl Build.PL
+./Build
+./Build test
+./Build install
+EOF
+}
+
 my $page = <<EOF;
 pod2text $self->{NAME}.pm > README

@@ -972,10 +1008,7 @@
 At the very least you should be able to use this set of instructions
 to install the module...

-perl Makefile.PL
-make
-make test
-make install
+$build_instructions

 If you are on a windows box you should use 'nmake' rather than 'make'.
 EOF
@@ -1101,6 +1134,106 @@

 ################################################ subroutine header begin ##

+=head2 FileText_Buildfile
+
+ Usage     : $self->FileText_Buildfile ()
+ Purpose   : Build a supporting file
+ Returns   : Text of the file being built
+ Argument  : n/a
+ Throws    : n/a
+ Comments  : This method is a likely candidate for alteration in a subclass
+
+See Also   :
+
+=cut
+
+################################################## subroutine header end ##
+
+sub FileText_Buildfile
+{
+	my ($self) = @_;
+
+	# As of 0.15, Module::Build only allows a few licenses
+	my $license_line = 1 if $self->{LICENSE} =~ /^(?:perl|gpl|artistic)$/;
+
+my $page = <<EOF;
+use Module::Build;
+# See perldoc Module::Build for details of how this works
+
+Module::Build->new
+    ( module_name     => '$self->{NAME}',
+EOF
+	if ($license_line) {
+$page .= <<EOF;
+      license         => '$self->{LICENSE}',
+EOF
+        }
+
+$page .= <<EOF;
+    )->create_build_script;
+EOF
+
+	return ($page);
+
+}
+
+################################################ subroutine header begin ##
+
+=head2 FileText_Proxy_Makefile
+
+ Usage     : $self->FileText_Proxy_Makefile ()
+ Purpose   : Build a supporting file
+ Returns   : Text of the file being built
+ Argument  : n/a
+ Throws    : n/a
+ Comments  : This method is a likely candidate for alteration in a subclass
+
+See Also   :
+
+=cut
+
+################################################## subroutine header end ##
+
+sub FileText_Proxy_Makefile
+{
+	my ($self) = @_;
+
+# This comes directly from the docs for Module::Build::Compat
+my $page = <<'EOF';
+unless (eval "use Module::Build::Compat 0.02; 1" ) {
+  print "This module requires Module::Build to install itself.\n";
+
+  require ExtUtils::MakeMaker;
+  my $yn = ExtUtils::MakeMaker::prompt
+    ('  Install Module::Build from CPAN?', 'y');
+
+  if ($yn =~ /^y/i) {
+    require Cwd;
+    require File::Spec;
+    require CPAN;
+
+    # Save this 'cause CPAN will chdir all over the place.
+    my $cwd = Cwd::cwd();
+    my $makefile = File::Spec->rel2abs($0);
+
+    CPAN::Shell->install('Module::Build::Compat');
+
+    chdir $cwd or die "Cannot chdir() back to $cwd: $!";
+    exec $^X, $makefile, @ARGV;  # Redo now that we have Module::Build
+  } else {
+    warn " *** Cannot install without Module::Build.  Exiting ...\n";
+    exit 1;
+  }
+}
+Module::Build::Compat->run_build_pl(args => \@ARGV);
+Module::Build::Compat->write_makefile();
+EOF
+
+	return ($page);
+}
+
+################################################ subroutine header begin ##
+
 =head2 FileText_Test

  Usage     : $self->FileText_Test ()
diff -ur ../ExtUtils-ModuleMaker-0.31229/scripts/modulemaker ./scripts/modulemaker
--- ../ExtUtils-ModuleMaker-0.31229/scripts/modulemaker	2003-02-15 12:08:26.000000000 -0600
+++ ./scripts/modulemaker	2003-03-15 03:29:21.000000000 -0600
@@ -39,6 +39,7 @@
 	my $string = $messages{'Main Menu'};
 	$string =~ s|##name##|$MOD->{NAME}|;
 	$string =~ s|##license##|$MOD->{LICENSE}|;
+	$string =~ s|##build##|$MOD->{BUILD_SYSTEM}|;

 	my $response = Question_User ($string, 'menu');

@@ -167,6 +168,32 @@
 	return ('License Menu');
 }

+
+################################################ subroutine header begin ##
+################################################## subroutine header end ##
+
+my %Build_Menu = (
+                                   E  => 'ExtUtils::MakeMaker',
+                                   B  => 'Module::Build',
+                                   P  => 'Module::Build and proxy Makefile.PL',
+                 );
+
+sub Build_Menu
+{
+	my $MOD = shift;
+
+	my $string = $messages{Build_Menu};
+	$string =~ s|##Build Here##|$MOD->{BUILD_SYSTEM}|;
+
+	my $response = Question_User ($string, 'menu');
+	return ($destinations{'Build Menu'}{$response}) if (exists $destinations{'Build Menu'}{$response});
+
+        $MOD->{BUILD_SYSTEM} = $Build_Menu{$response} if exists $Build_Menu{$response};
+
+	return ('Build Menu');
+}
+
+
 ################################################ subroutine header begin ##
 ################################################## subroutine header end ##

@@ -269,6 +296,7 @@
     -l   Specify a license for this extension.
     -n   Specify a name to use for the extension (required).
     -v   Specify a version number for this extension.
+    -b   Specify a build system for this extension.
     -P   Omit the stub POD section.
     -C   Omit creating the Changes file, add HISTORY heading to stub POD.
     -I   Disable INTERACTIVE mode, the command line arguments better be complete
@@ -296,6 +324,7 @@
 							 A	=> 'Author Menu',
 							 L	=> 'License Menu',
 							 D	=> 'Directives_Menu',
+                                                         B      => 'Build Menu',
 							 Q	=> 'done',
 						   },
 	 'Author Menu'		=> {
@@ -313,6 +342,11 @@
 							 Q	=> 'done',
 							 P	=> 'License Menu',
 						   },
+
+	 'Build Menu'   	=> {
+							 R	=> 'Main Menu',
+							 Q	=> 'done',
+						   },
 	);

 ###########################################################################
@@ -330,6 +364,7 @@
 A - Author information
 L - License              '##license##'
 D - Directives
+B - Build system         '##build##'
 G - Generate module

 Q - Quit program
@@ -412,12 +447,27 @@
 EOF

 	 #---------------------------------------------------------------------
+
+	 Build_Menu		=> <<EOF,
+Here is the current build system:
+
+##Build Here##
+
+E - ExtUtils::MakeMaker
+B - Module::Build
+P - Module::Build and proxy Makefile.PL
+R - Return to main menu
+
+Please choose which build system you would like to use:
+EOF
+
+	 #---------------------------------------------------------------------
 	);

 ###########################################################################
 ###########################################################################

-getopts ("dhCIPVcn:v:l:", \%opts);
+getopts ("bdhCIPVcn:v:l:", \%opts);
 die Usage () if ($opts{h});

 my $where = 'Main Menu';
@@ -425,6 +475,8 @@
 			(
 				NAME			=> $opts{n},

+                                (($opts{b}) ? (BUILD_SYSTEM     => $opts{b}) : ()),
+
 				COMPACT			=> (($opts{c}) ? 1 : 0),
 				VERBOSE			=> (($opts{V}) ? 1 : 0),
 				CHANGES_IN_POD	=> (($opts{C}) ? 1 : 0),
@@ -457,6 +509,8 @@
 			$where = Copyright_Display ($MOD);
 		} elsif ($where eq 'Directives_Menu') {
 			$where = Directives_Menu ($MOD);
+		} elsif ($where eq 'Build Menu') {
+			$where = Build_Menu ($MOD);
 		} else {
 			$where = Main_Menu ($MOD);
 		}

Re: [Module-build-general] Question about Defaults ...

[Nicholas C. <ni...@un...>]

On Fri, Mar 14, 2003 at 12:45:17PM -0600, Dave Rolsky wrote:
> h2xs for module creation needs to die along with MakeMaker ;)

and xsubpp (being worked on, IIRC) etc

h2xs isn't going to die in 5.8.1
But I suspect that there's still time to get a patch for 5.8.1 in to add an
option to h2xs to make the module use Module::Build rather than MakeMaker

Nicholas Clark

Re: [Module-build-general] Question about Defaults ...

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

On Friday, March 14, 2003, at 12:45  PM, Dave Rolsky wrote:

> On Fri, 14 Mar 2003, Norbert Gruener wrote:
>
>> My question is, what is the reason for this requirement ?  And is
>> there a possibility to switch off this behavior ?  Of course, I know
>> how to accomplish your requirement :-).  But this would mean that I
>> have to fiddle about the directory structure after running the initial
>> h2xs.
>
> I think Ken did this cause it's easy ;)

Yeah, that was a big part of it.  I've had to convert several of my own 
projects to this layout too, so I know it's a (little) hassle.

I've had people tell me that it was a good decision though, so I'd like 
to hear more arguments on either side.  I think that using just lib/ 
makes things easier not just for me, but for people who are trying to 
figure out how modules put themselves together during the build 
process.  But I'm sympathetic to the migration issues too.


> Seriously, I'm sure he'd welcome support for alternate layouts.  By
> default, I think it should look in lib/ and then the current directory 
> for
> .pm and .pod files.  With MakeMaker, there's also a way to map a 
> different
> layout to the installation layout, using the PM option.  I'm not sure 
> this
> is really worthwhile, though.

There are other issues to consider too.  Right now MakeMaker looks for 
subdirectories containing Makefile.PLs and builds stuff recursively in 
these directories.  This is actually the only way you can have more 
than one .xs file in a distribution using MakeMaker.

M::B doesn't do recursive subdirectories at this point either.  It's 
not usually a problem because M::B will compile .xs files inside lib/ , 
which MakeMaker won't do.

If we add the ability to have sub-builds in subdirectories, I'm 
probably going to insist that these subdirectories are explicitly 
listed in the Build.PL, rather than auto-detected.  I've never cared 
for the auto-detect stuff in MakeMaker, and it was a big reason why I 
wanted Every Installable Thing In Lib/ (sic).

  -Ken

Re: [Module-build-general] META.yml extraction on CPAN

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

On Thursday, March 13, 2003, at 07:22  PM, Andreas J. Koenig wrote:

> Autrijus suggested to me to start extracting the META.yml files as
> we're doing for the README. So I did. The first yaml file has been
> extracted for Casey West:
>
> -rw-rw-r--    1 root     root          366 Mar 12 21:42 
> poest-0.20030312.readme
> -rw-rw-r--    1 root     root          327 Mar 12 21:44 
> poest-0.20030312.meta
> -rw-rw-r--    1 root     root        14014 Mar 12 21:46 
> poest-0.20030312.tar.gz

Good idea.

>
> I realize now that META.yml should contain some protocol.version tag
> so that the reader knows which fields he can expect.

Good point - I included the "generated_by" field for this purpose, but 
an independent protocol field would probably serve the need better.

> And a spec, what
> the file contains and a revision history of the spec to know what a
> specific file contains or should contain depending on
> protocol.version. And a URL for the spec so that we can point to it.
>
> OK, a subset of all this will do.

I just wrote up http://module-build.sourceforge.net/META-spec.html , 
see whether that fills the need.  It describes the META.yml files as 
created by Module::Build version 0.16.  It's a little informal, but I 
guess we don't need formality yet.

Probably the first revision we'd make is to add a field like 
"meta_protocol" for specifying the version of the protocol, like you 
suggested.

  -Ken

Re: [Module-build-general] Question about Defaults ...

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

On Fri, 14 Mar 2003, Norbert Gruener wrote:

> Since I think this is a very good approach, I started to look into
> your module if I could convert to your way of installing.
> Unfortunately I found out that you are expecting all module files (.pm
> or .xs) sitting in the directory "lib/".  But this directory structure
> is not the default structure when you are starting your development by
> using "h2xs".

h2xs for module creation needs to die along with MakeMaker ;)

> My question is, what is the reason for this requirement ?  And is
> there a possibility to switch off this behavior ?  Of course, I know
> how to accomplish your requirement :-).  But this would mean that I
> have to fiddle about the directory structure after running the initial
> h2xs.

I think Ken did this cause it's easy ;)

Seriously, I'm sure he'd welcome support for alternate layouts.  By
default, I think it should look in lib/ and then the current directory for
.pm and .pod files.  With MakeMaker, there's also a way to map a different
layout to the installation layout, using the PM option.  I'm not sure this
is really worthwhile, though.


-dave

/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/

[Module-build-general] Question about Defaults ...

[Norbert G. <no...@MP...>]

Dear Module::Build designers,

recently I have read the article on Perl.com about your module
Module::Build.  I was very fascinated by your idea to handle the
complete installation procedure of modules under the control of Perl.
This is a very fine module, well done :-))

Since I think this is a very good approach, I started to look into
your module if I could convert to your way of installing.
Unfortunately I found out that you are expecting all module files (.pm
or .xs) sitting in the directory "lib/".  But this directory structure
is not the default structure when you are starting your development by
using "h2xs".

My question is, what is the reason for this requirement ?  And is
there a possibility to switch off this behavior ?  Of course, I know
how to accomplish your requirement :-).  But this would mean that I
have to fiddle about the directory structure after running the initial
h2xs.

Cheers,

Norbert
-- 
Ceterum censeo          | PGP encrypted mail preferred.
Redmond esse delendam.  | PGP Key at www.MPA-Garching.MPG.de/~nog/

[Module-build-general] Perl Compiler Collection

[Randy W. S. <Ra...@Th...>]

On 2/26/2003 10:04 AM, Ken Williams wrote:
 >
 > On Tuesday, February 25, 2003, at 06:53  PM, Randy W. Sims wrote:
 >
 >> On 2/24/2003 12:56 PM, Ken Williams wrote:
 >>
 >>> That can wait until the future.  To do this cleanly, I think we could
 >>> create a module like ExtUtils::C with classes like
 >>> ExtUtils::C::Compiler and ExtUtils::C::Linker that Module::Build
 >>> could just use transparently.  Its purpose would be to compile and
 >>> link things that will be linked in with Perl modules (not a general
 >>> tool for arbitrary C code), using the same interface regardless of
 >>> platform.
 >>> We could use that module in other situations too, like in the testing
 >>> code for ExtUtils::ParseXS.
 >>> Probably the code you've written for Win32 and the code I wrote for
 >>> Unix would be a good start toward such a module.  But given that the
 >>> module doesn't exist yet, we'll just have to wait. =)
 >>
 >>
 >> I've been thinking very seriously about writing those modules. My
 >> problem is the more I think about it the more ambitious the design
 >> becomes. I'm more inclined at the moment to design them as a framework
 >> not limited to 'C' and 'XS', so that Inline::* modules could make use
 >> of the framework if desired. Instead of ExtUtils::C::Linker, there
 >> would be something like:
 >>
 >> my $cc = new ExtUtils::Compiler(
 >>   LANG  => 'C',
 >>   FLAGS => ...
 >> );
 >>
 >> $cc->compile( source => 'source.c', output => 'source.o' );
 >>
 >> In other words, it would operate like 'gcc' does, where it is a
 >> front-end driver for any number of different compilers.
 >
 >
 > Eek, dangerous road! ;-)  When I've entertained writing this, it's only
 > by limiting the scope of the design that I can convince myself it's
 > worth doing, because I might have a reasonable chance of ever 
finishing. =)
 >
 > That said, probably all you'd need to do is define the *interfaces*,
 > implement the stuff we need for C compilation, and let other people
 > provide the code to support various languages.


I've been playing catch-up for the last few days...

(If you or anyone one you know uses any of those legal pep-pills with 
Ephedrine, STOP. I've abused those pill for a few years now, trying to 
sqeeze more time out of each day, but I ended up going to the hospital 
the Sunday before last because my blood-pressure went thru the roof. For 
about a week I was back-and-forth between doctor and hospital for tests 
because of those stupid pills. Needless to say, I will be taking no more 
of those (not to mention the gallons of coffee I drink each week)--Thiry 
is much too young for that kind of drama. --END OF PUBLIC SAFETY MESSAGE :)

Anyway. If you still think it would be a good idea to develop these 
modules, I think I'll get started on them (finally!) this weekend. I 
would like to work with you to make sure that what I come up with will 
be appropriate for M::B.

I do plan to limit the initial scope to XS/C/C++ as that is all that is 
required for perl extensions (that I've encountered), but I also want to 
try to keep it open ended where feasible so it can be extended later.

I have more than a few pages of notes I've jotted down over the past 
month or so that I need to put together for my initial spec., but here 
are some of the main points of what I propose:

The modules will be in the namespace ExtUtils::PCC (Perl Compiler 
Collection). I'm open to better name suggestions.

The main modules will be Compiler, Linker, Archiver (???), and Shell. 
The latter will be used by the others for shell quoting, finding 
executables, and invoking the respective tool, etc.

Each of the main modules will have subclasses based on the name of the 
compiler/linker. I'm not sure if there is any need for anything platform 
specific here; If so maybe I can have the main class try looking for a 
an appropriate class by generating several permutations on tool name, 
tool version, and platform--going from most specific to most general. 
For example it might first look for a module gcc_3*_linux, if not found 
then gcc_3* and finally gcc. Or, something like that; implementation 
often diverges from the initial idealization.

Primary responsibilities of these modules would include 
compiling/linking dynamic extensions, static extensions, and 
compiling/linking dependent libraries (ex. Compiler::Zlib). Optionally 
future versions could allow querying capabilities/information about the 
tool (Ex. invoking gcc --version to return the exact version, etc).

When constructing the object the user can specify whether or not an 
extension is being built (as opposed to a support lib). If it is an 
extension then the various flags and defines specified in Config.pm will 
be included in the commands as appropriate.

Default construction will use the compiler/linker/shell etc. specified 
in Config.pm unless overriden by user.

Each of Compiler/Linker/Archiver will specify generic option names that 
can be used to set options that are common (i.e. generate debugging 
info, set optimization level, set output file name, etc).

Each class will keep track of files that are generated.

Any ideas, suggestions, criticism are welcome. I don't /think/ it would 
take very long to get an initial implementation working that abstracted 
away what is done in M::B & EU::MakeMaker.

Randy.

[Module-build-general] META.yml extraction on CPAN

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

Autrijus suggested to me to start extracting the META.yml files as
we're doing for the README. So I did. The first yaml file has been
extracted for Casey West:

-rw-rw-r--    1 root     root          366 Mar 12 21:42 poest-0.20030312.readme
-rw-rw-r--    1 root     root          327 Mar 12 21:44 poest-0.20030312.meta
-rw-rw-r--    1 root     root        14014 Mar 12 21:46 poest-0.20030312.tar.gz

I realize now that META.yml should contain some protocol.version tag
so that the reader knows which fields he can expect. And a spec, what
the file contains and a revision history of the spec to know what a
specific file contains or should contain depending on
protocol.version. And a URL for the spec so that we can point to it.

OK, a subset of all this will do.

What do we have? What do you suggest?

-- 
andreas

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

[Jan D. <ja...@Ac...>]

On Wed, 12 Mar 2003 16:54:01 -0600, Ken Williams <ke...@ma...>
wrote:

[You need to subscribe to the mailing list in order to post here; it is
not a moderated list, so messages from non-subscribers waiting in the
moderation queue may take a looooong time to appear on the list.]

>> ActiveState regularly performs an automated build and packaging (PPM) 
>> of modules on CPAN. If the module builds without problem it is 
>> automatically placed in their repository (as M::B currently is for 
>> most AS supported archs). It looks like you can check the status at
>> <http://ppm-ia.activestate.com>
>>
>> Currently there is only one failure: perl-5.8 on hpux-ia64-lp64 (Hmm, 
>> it passes with perl-5.6 on same arch; Unfortunately there doesn't seem 
>> to be any log for the failures.)

The automated build system is currently offline due to maintenance.  It
should get online again soonish (this month).

>Hmm, I wonder whether there's some way to see the output?  It would be 
>helpful if they were linked.  Anyone at the PPM list have the power to 
>make it so?

Yes, we are going to do that too.

Cheers,
-Jan

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

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

On Tuesday, March 11, 2003, at 11:54  PM, Randy W. Sims wrote:

> ActiveState just opened a new list for PPM which I've CC'd so that 
> maybe Jan Dubois and Co. can offer some suggestions/insights.

Cool.

> The ppd target prints a simple xml file describing the distribution 
> for PPM. The format is based on the Open Software Description format 
> <http://www.w3.org/TR/NOTE-OSD.html>
>

Thanks for the reference, I hadn't seen that yet.

> The only problem with the ppd target under M::B is specifying prereqs-
> How will M::B's more dynamic & flexible dependencies be specified in 
> the static ppd file? (rf.
>  <http://sourceforge.net/mailarchive/forum.php
>   ?thread_id=1676522&forum_id=10905>
> ).

Yeah, that may be an issue.  I'd like to get the META.yml file to line 
up better, at least conceptually, with the PPD file.


> ActiveState regularly performs an automated build and packaging (PPM) 
> of modules on CPAN. If the module builds without problem it is 
> automatically placed in their repository (as M::B currently is for 
> most AS supported archs). It looks like you can check the status at
> <http://ppm-ia.activestate.com>
>
> Currently there is only one failure: perl-5.8 on hpux-ia64-lp64 (Hmm, 
> it passes with perl-5.6 on same arch; Unfortunately there doesn't seem 
> to be any log for the failures.)

Hmm, I wonder whether there's some way to see the output?  It would be 
helpful if they were linked.  Anyone at the PPM list have the power to 
make it so?

  -Ken

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

[Randy W. S. <Ra...@Th...>]

ActiveState just opened a new list for PPM which I've CC'd so that maybe 
Jan Dubois and Co. can offer some suggestions/insights.

On 3/4/2003 3:48 PM, Ken Williams wrote:
> 
> On Tuesday, March 4, 2003, at 02:38  PM, Bri...@AR... wrote:
> 
>> Ken -
>>
>> I downloaded and installed Module::Build 0.16 on my Win32 ActiveState 
>> Perl
>> 5.6 without a hitch.  Great work!  Much smoother than the 0.15
>> installation I conversed with you about last month.
>>
>> I've attached a PPM package for Win32 ActiveState Perl 5.6 
>> installation of
>> Module::Build 0.16 -- Feel free to use it and distribute if you like.
>> Note, my crappy mailer (Lotus Notes) will probably munge the name to 
>> 8.3 -
>> it's originally 'Module-Build-0.16_ppm.tar.gz'
>>
>> I'm not sure what's involved (too busy to dig in right now), but
>> supporting a build target of 'ppd' mirroring the functionality of the
>> existing MakeMaker system will ease generation of these package for 
>> future
>> users of Module::Build.
> 
> 
> Awesome, thanks for testing and for the PPM.  I'm quite interested in 
> supporting a 'ppd' action (both for M::B itself and for other modules 
> built using M::B), so at some point I'll want to figure out how to do 
> this properly.  How did you create this one?

The ppd target prints a simple xml file describing the distribution for 
PPM. The format is based on the Open Software Description format 
<http://www.w3.org/TR/NOTE-OSD.html>

The only problem with the ppd target under M::B is specifying prereqs-
How will M::B's more dynamic & flexible dependencies be specified in the 
static ppd file? (rf.
  <http://sourceforge.net/mailarchive/forum.php
   ?thread_id=1676522&forum_id=10905>
).

> Where's the best place for me to put the PPM tarball?  I can certainly 
> upload it to my CPAN directory, should I also see about getting it in 
> the ActiveState repository or something?
> 
>  -Ken

ActiveState regularly performs an automated build and packaging (PPM) of 
modules on CPAN. If the module builds without problem it is 
automatically placed in their repository (as M::B currently is for most 
AS supported archs). It looks like you can check the status at
<http://ppm-ia.activestate.com>

Currently there is only one failure: perl-5.8 on hpux-ia64-lp64 (Hmm, it 
passes with perl-5.6 on same arch; Unfortunately there doesn't seem to 
be any log for the failures.)

Randy.

Re: [Module-build-general] [PATCH] MSWin32 override make_executable() to call pl2bat utility.

[Randy W. S. <Ra...@Th...>]

On 3/11/2003 11:31 AM, Ken Williams wrote:
> Thanks - I've applied it, finally.
> 
> The make_executable() routine is called for any script requiring 
> execution privileges, does it make sense to always create a .bat file, 
> even for things like the Build script?
> 
>  -Ken

It makes sense to call it on any script that will be installed on the 
users system in as much as this was the behaviour under MakeMaker. It 
does explicitly skip the Build script, or rather, anything named in 
$self->{properties}{build_script}.

IME, it's really not needed at all except where the script is expected 
to handle redirection at the commandline. It may make more sense to use 
pl2bat as an optional filter to be run only when the module author 
explicitly asks for it. However, it seemed safest to follow the 
convention established by MakeMaker, running pl2bat on all scripts that 
are to be installed.

Randy.

Re: [Module-build-general] [PATCH] MSWin32 override make_executable() to call pl2bat utility.

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

Thanks - I've applied it, finally.

The make_executable() routine is called for any script requiring 
execution privileges, does it make sense to always create a .bat file, 
even for things like the Build script?

  -Ken

On Saturday, March 1, 2003, at 03:33  PM, Randy W. Sims wrote:

> Calls the pl2bat utility (distributed with the perl core) on perl 
> scripts which adds a short batch startup script to the file which 
> invokes perl. As per MakeMaker both the .pl and the new .bat file will 
> be installed. See the documentation in 
> <perl-source>/win32/bin/pl2bat.pl and in the 
> <perl-source>/README.win32 file in the section 'Usage Hints' - 
> 'Running Perl Scripts' for details.
>
> Randy.
> 18d17
> <   # Check compiler type.
> 19a19,20
>>
>>   # Check compiler type.
> 31a33,47
>>   # Find 'pl2bat.bat' utility used for installing perl scripts.
>>   # This search is probably overkill, as I've never met a MSWin32 perl
>>   # where these locations differed from each other.
>>   my @potential_dirs = map { File::Spec->canonpath($_) }
>>     @${cf}{qw(installscript installbin installsitebin 
>> installvendorbin)},
>>     File::Basename::dirname($self->{properties}{perl});
>>
>>   foreach my $dir (@potential_dirs) {
>>     my $potential_file = File::Spec->catfile($dir, 'pl2bat.bat');
>>     if ( -f $potential_file && !-d _ ) {
>>       $cf->{pl2bat} = $potential_file;
>>       last;
>>     }
>>   }
>>
> 192a209,237
>> sub make_executable {
>>   my $self = shift;
>>   $self->SUPER::make_executable(@_);
>>
>>   my $pl2bat = $self->{config}{pl2bat};
>>
>>   if ( defined($pl2bat) && length($pl2bat) ) {
>>     foreach my $script (@_) {
>>       # Don't run 'pl2bat.bat' for the 'Build' script;
>>       # there is no easy way to get the resulting 'Build.bat'
>>       # to delete itself when doing a 'Build realclean'.
>>       next if ( $script eq $self->{properties}{build_script} );
>>
>>       (my $script_bat = $script) =~ s/\.plx?//i;
>>       $script_bat .= '.bat' unless $script_bat =~ /\.bat$/i;
>>
>>       my $status = $self->do_system($pl2bat, '<', $script, '>', 
>> $script_bat);
>>       if ( $status && -f $script_bat ) {
>>         $self->SUPER::make_executable($script_bat);
>>       } else {
>>         warn "Unable to convert '$script' to an executable.\n";
>>       }
>>     }
>>   } else {
>>     warn "Could not find 'pl2bat.bat' utility needed to make scripts 
>> executable.\n"
>>        . "Unable to convert scripts ( " . join(', ', @_) . " ) to 
>> executables.\n";
>>   }
>> }

Re: [Module-build-general] More version info in META.yml

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

>>>>> On Sat, 8 Mar 2003 13:53:25 -0800, sc...@po... (Michael G. Schwern) said:

  > On Sat, Mar 08, 2003 at 01:43:37PM -0600, Ken Williams wrote:
 >> >>   2) What about .pm files that contain multiple packages?  Should 
 >> >> those
 >> >> packages be included too, like the PAUSE namespace indexer does?
 >> >
 >> > Is the PAUSE indexer that smart?  I don't think it is.
 >> 
 >> Yup, it is:

  > Maybe we should borrow the code then?

In case you don't know, PAUSE code is available in a subversion
repository and in daily snapshots. Daily dumps of the subversion repo
are also there. The dumps and snapshots are at

    ftp://pause.perl.org/pub/PAUSE/PAUSE-code/

The repository itself is

    http://pause.perl.org:5459/svn/pause/trunk
or
    https://pause.perl.org:5460/svn/pause/trunk

The http adresses can also be browsed.

The indexer is in cron/mldistwatch.

Problem is, it is not a tiny program but 2000+ lines long and probably
not easy to follow and dissect. What do you suggest?


-- 
andreas

Re: [Module-build-general] More version info in META.yml

[<sc...@po...>]

On Sat, Mar 08, 2003 at 01:43:37PM -0600, Ken Williams wrote:
> >>   2) What about .pm files that contain multiple packages?  Should 
> >> those
> >> packages be included too, like the PAUSE namespace indexer does?
> >
> > Is the PAUSE indexer that smart?  I don't think it is.
> 
> Yup, it is:

Maybe we should borrow the code then?

Re: [Module-build-general] More version info in META.yml

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

On Saturday, March 8, 2003, at 01:38  PM, sc...@po... wrote:

> On Sat, Mar 08, 2003 at 12:15:18PM -0600, Ken Williams wrote:
>
>>   2) What about .pm files that contain multiple packages?  Should 
>> those
>> packages be included too, like the PAUSE namespace indexer does?
>
> Is the PAUSE indexer that smart?  I don't think it is.

Yup, it is:

<<<<<<<<<<<<<<<<<<<<<< PAUSE indexer report <<<<<<<<<<<<<<<<<<<<<
...
Module::Build::Platform::Windows
     version: undef
     in file: Module-Build-0.16/lib/Module/Build/Platform/Windows.pm
      status: indexed

Module::Build::Platform::Windows::BCC
     version: undef
     in file: Module-Build-0.16/lib/Module/Build/Platform/Windows.pm
      status: indexed

Module::Build::Platform::Windows::GCC
     version: undef
     in file: Module-Build-0.16/lib/Module/Build/Platform/Windows.pm
      status: indexed

Module::Build::Platform::Windows::MSVC
     version: undef
     in file: Module-Build-0.16/lib/Module/Build/Platform/Windows.pm
      status: indexed
...
<<<<<<<<<<<<<<<<<<<<<< PAUSE indexer report <<<<<<<<<<<<<<<<<<<<<

  -Ken

Re: [Module-build-general] More version info in META.yml

[<sc...@po...>]

On Sat, Mar 08, 2003 at 12:15:18PM -0600, Ken Williams wrote:
>   1) Would this be better in a separate file like VERSIONS or something? 
>   Probably not, but I just wanted to throw out the idea.  The list could 
> get pretty big for some distributions.  Maybe that's okay.

It shouldn't be necessary to split it up, no.  I think it would just confuse
things anyway.


>   2) What about .pm files that contain multiple packages?  Should those 
> packages be included too, like the PAUSE namespace indexer does?

Is the PAUSE indexer that smart?  I don't think it is.

Anyhow, doing that correctly sounds like Work.

Re: [Module-build-general] More version info in META.yml

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

On Thursday, March 6, 2003, at 09:58  AM, sc...@po... wrote:

> I was talking with Andreas last night about the META.yml idea.  He 
> mentioned
> that it would be useful for PAUSE if in addition to having just the
> version # for the whole distribution, it also had the version # for all
> .pm files in the dist.  That way PAUSE wouldn't have to check itself
> (involving some gymnastics to make it safe).
>
> At our end, its pretty simple.  We just run the moral equivalent of
> ExtUtils::MakeMaker->parse_version on each .pm file and encode that,
> something like:
>
> modules:
> 	Module::Build:		0.16
>     	Module::Build::Base:
> 	Module::Build::Compat:	0.02
> 	...etc...
>
> Thoughts?
>

I think that makes sense.  A couple of questions, though:

  1) Would this be better in a separate file like VERSIONS or something? 
  Probably not, but I just wanted to throw out the idea.  The list could 
get pretty big for some distributions.  Maybe that's okay.

  2) What about .pm files that contain multiple packages?  Should those 
packages be included too, like the PAUSE namespace indexer does?

  -Ken

Re: [Module-build-general] A mini-language for dependencies?

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

On 07/03/03 15:17 -0600, Ken Williams wrote:
> 
> On Thursday, March 6, 2003, at 02:48  AM, sc...@po... wrote:
> 
> > On Thu, Mar 06, 2003 at 11:51:12AM +0800, Autrijus Tang wrote:
> >> build_requires:
> >>   Test::More: {}
> >> recommends:
> >>   Acme::ComeFrom:
> >>     alternate:
> >>       Acme::ComeWith:
> >>         version: 0.05
> >>     reason: "I really likes it"
> >>     version: 0.02
> >
> > The 'alternate' syntax feels better handled like so
> >
> >     recommends:
> >       Text::Bastardize:  0
> >       Net Transport Agent:
> >         LWP:	     1.25
> >         Net::FTP:    0.24

FWIW, This is also valid YAML:

  recommends:
    Text::Bastardize:  0
    Net Transport Agent: { LWP: 1.25, Net::FTP: 0.24 }

> > ie. what you need it for then those modules which will fulfill the 
> > need.
> > Its simple to read and write.
> >
> > And then when you need all the extra information (arch, perl, etc...)
> > there's an optional rich syntax like you have below.
> 
> I'm not sure I'm convinced that YAML is really the best way to write 
> this information.  That's why I suggested the creation of a 
> mini-language - YAML is a language for creating data structures, not 
> declarations of dependencies.  My sense is that forcing things into 
> YAML tends to obscure the information.
> 
> If it can be done in easy YAML, and still be eminently readable, I'm 
> all for it.  It does make the parsing easier.  But I don't think it's 
> great to use 3-level nesting in the META.yml files, because you lose 
> the human readability and the ability to use brain-dead parsing on them.
> 
> That said, the real work in this task isn't in the parsing, it's in 
> turning the parse into a real check of the dependencies.  So I'm not 
> sure there's a whole lot to gain by using YAML either.  Recall that the 
> easy cases (modules with completely static dependencies) can just be 
> expressed using the current YAML declarations, so it's only the messy 
> cases that will need to use this anyway.
> 
> I should be able to post a counter-proposal within the next couple of 
> days.
> 
>   -Ken
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

Re: [Module-build-general] A mini-language for dependencies?

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

On Thursday, March 6, 2003, at 02:48  AM, sc...@po... wrote:

> On Thu, Mar 06, 2003 at 11:51:12AM +0800, Autrijus Tang wrote:
>> build_requires:
>>   Test::More: {}
>> recommends:
>>   Acme::ComeFrom:
>>     alternate:
>>       Acme::ComeWith:
>>         version: 0.05
>>     reason: "I really likes it"
>>     version: 0.02
>
> The 'alternate' syntax feels better handled like so
>
>     recommends:
>       Text::Bastardize:  0
>       Net Transport Agent:
>         LWP:	     1.25
>         Net::FTP:    0.24
>
> ie. what you need it for then those modules which will fulfill the 
> need.
> Its simple to read and write.
>
> And then when you need all the extra information (arch, perl, etc...)
> there's an optional rich syntax like you have below.

I'm not sure I'm convinced that YAML is really the best way to write 
this information.  That's why I suggested the creation of a 
mini-language - YAML is a language for creating data structures, not 
declarations of dependencies.  My sense is that forcing things into 
YAML tends to obscure the information.

If it can be done in easy YAML, and still be eminently readable, I'm 
all for it.  It does make the parsing easier.  But I don't think it's 
great to use 3-level nesting in the META.yml files, because you lose 
the human readability and the ability to use brain-dead parsing on them.

That said, the real work in this task isn't in the parsing, it's in 
turning the parse into a real check of the dependencies.  So I'm not 
sure there's a whole lot to gain by using YAML either.  Recall that the 
easy cases (modules with completely static dependencies) can just be 
expressed using the current YAML declarations, so it's only the messy 
cases that will need to use this anyway.

I should be able to post a counter-proposal within the next couple of 
days.

  -Ken

[Module-build-general] More version info in META.yml

[<sc...@po...>]

I was talking with Andreas last night about the META.yml idea.  He mentioned
that it would be useful for PAUSE if in addition to having just the
version # for the whole distribution, it also had the version # for all
.pm files in the dist.  That way PAUSE wouldn't have to check itself
(involving some gymnastics to make it safe).

At our end, its pretty simple.  We just run the moral equivalent of
ExtUtils::MakeMaker->parse_version on each .pm file and encode that,
something like:

modules:
	Module::Build:		0.16
    	Module::Build::Base:
	Module::Build::Compat:	0.02
	...etc...

Thoughts?

Re: [Module-build-general] A mini-language for dependencies?

[<sc...@po...>]

On Thu, Mar 06, 2003 at 11:51:12AM +0800, Autrijus Tang wrote:
> build_requires:
>   Test::More: {}
> recommends:
>   Acme::ComeFrom:
>     alternate:
>       Acme::ComeWith:
>         version: 0.05
>     reason: "I really likes it"
>     version: 0.02

The 'alternate' syntax feels better handled like so

    recommends:
      Text::Bastardize:  0
      Net Transport Agent:
        LWP:	     1.25
        Net::FTP:    0.24

ie. what you need it for then those modules which will fulfill the need.
Its simple to read and write.

And then when you need all the extra information (arch, perl, etc...) 
there's an optional rich syntax like you have below.


> requires:
>   Some::Module:
>     arch: MSWin32
>     perl: 5.6.0
>     version: 1.04
>   Other::Module:
>     version 1.53
>   arch: '!Solaris'
>   perl: 5.005
> features:
>   - name: This is feature one
>     requires:
>       arch: MSWin32
>       Module::Foo:
>         perl: '<5.6.0'
>         version: 2.04
>   - name: Feature two
>     requires:
>       Lingua::ZH::TaBE: {}
>     recommends:
>       Lingua::EN::Inflect:
>         arch: '!MSWin32'
>         version: 3.03



--