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

RE: [Module::Build] Problem building XS modules on AIX

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

On Tue, 18 Nov 2003 09:36:50 -0600, James.FitzGibbon wrote:

Hi James

> The patch is attached; if someone could please test building M::B

Nothing attached here.
-- 
Ron Savage, ro...@de... on 19/11/2003. Room EF 312
Deakin University, 221 Burwood Highway, Burwood, VIC 3125, Australia
Phone: +61-3-9251 7067, Fax: +61-3-9251 7604
http://www.deakin.edu.au/~rons

RE: [Module::Build] Problem building XS modules on AIX

[James.FitzGibbon <Jam...@ta...>]

> I'm having a few problems that I'll have to work out in the morning.
The exp file is
> being created, but EU::Mksyms is putting it in blib one level deeper
than the substitution
> on $lddlflags is subsequently looking for it.  I think the way that
Ken W. compiles XS
> code as part of his test suite is throwing the main M::B build into a
loop, but I can just
> bypass the test suite until I can solve the first problem.

I've updated Randy's patch to find the .exp files in the right place on
AIX, but I
don't have the necessary Windows environment to see if I've broken
things there.

The patch is attached; if someone could please test building M::B itself
and let me
know what the results are.  If it fails and you have the time, output
from building
M::B 0.21 (with and without the patch) and Pod::Coverage 0.11 and 0.12
(one uses EU::MM
while the other M::B) without the patch would help to clarify .exp file
locations.

The main problem seems to be that the generation of the .exp file is in
a common part of
M::B (Base.pm) but the use of the .exp file in the link phase is in a
platform-specific
place (Windows.pm and aix.pm).  There doesn't seem to be a single way to
tell both
EU::Mksymlists and all of the compilers out there explicitly what the
.exp or .def file
is supposed to be named.  EU::Mksymlists just knows based upon the four
platforms it
supports but doesn't return that value back to the caller.

Perhaps what is needed is to update EU::Mksymlists to both export the
platform-specific
extensions as constants and return the canonical path to the written
file back to it's
caller so that link_c() in M::B can act more intelligently.

Thanks.

[Module::Build] Data::FormValidator + Module::Build : local prefix install fails under linux

[Terrence B. <met...@ur...>]

princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : perl 
Makefile.PL PR\
EFIX=$PREFIX
/usr/bin/perl Build.PL config=prefix=/home/princepawn/install
Deleting _build
Creating custom builder _build/lib/Data/FormValidator/Builder.pm in 
_build/lib/\
Data/FormValidator
Checking whether your kit is complete...
Looks good
Deleting Build
Removed previous script 'Build'
Creating new 'Build' script for 'Data-FormValidator' version '3.14'
princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : echo $PREFIX
/home/princepawn/install
princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : make install
/usr/bin/perl Build install
Warning: You do not have permissions to install into 
/usr/local/share/perl/5.8.\
0 at /usr/share/perl/5.8.0/ExtUtils/Install.pm line 114.
mkdir /usr/local/share/perl/5.8.0/Data: Permission denied at 
/usr/share/perl/5.\
8.0/ExtUtils/Install.pm line 176
make: *** [install] Error 255
princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 : uname -a
Linux perlmonk.org 2.4.18 #12 Fri Sep 13 17:49:41 EDT 2002 i686 GNU/Linux
princepawn@perlmonk ~/.cpan/build/Data-FormValidator-3.14 :

Re: [Module::Build] Problem building XS modules on AIX

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

James.FitzGibbon wrote:

>>>Any feedback appreciated.
>>>
> 
> 
>>I'm the one who wrote Windows.pm. Can you post your perl Config.pm. 
>>Other than calling Mksymlists, it looks like we need to do some
> 
> variable 
> 
>>substitutions on some of the $Config variables, and I'll need to see 
>>Config.pm to know which ones.
> 
> 
> I'll spare list bandwidth by sending the config output direct to you.
> 
> I had gotten things a bit closer by copying the technique you use in
> Windows.pm.
> Basically add a prelink_c to M::B::Base with an empty stub and then make
> an AIX platform that tries to do what Windows::prelink_c() does, but the
> variable substitution part is still dogging me.  I presume it's
> something
> similar to your format_compiler_cmd() subroutine as opposed to setting
> something
> in the environment based upon values from Config?
> 
> Thanks.
> 

Sorry to take so long; I had to leave for a meeting. Sounds like you 
mostly had it working. The substitutions where minor as you can see from 
the patch. You might have to tweak this as I don't have AIX to test on; 
in fact I'm doing this on a laptop with no compiler, so I've had to 
parse it mentally, but it should be pretty close.

Let me know if this works.

Thanks,
Randy.

RE: [Module::Build] Problem building XS modules on AIX

[James.FitzGibbon <Jam...@ta...>]

> > Any feedback appreciated.
> >=20

> I'm the one who wrote Windows.pm. Can you post your perl Config.pm.=20
> Other than calling Mksymlists, it looks like we need to do some
variable=20
> substitutions on some of the $Config variables, and I'll need to see=20
> Config.pm to know which ones.

I'll spare list bandwidth by sending the config output direct to you.

I had gotten things a bit closer by copying the technique you use in
Windows.pm.
Basically add a prelink_c to M::B::Base with an empty stub and then make
an AIX platform that tries to do what Windows::prelink_c() does, but the
variable substitution part is still dogging me.  I presume it's
something
similar to your format_compiler_cmd() subroutine as opposed to setting
something
in the environment based upon values from Config?

Thanks.

--=20
j.

Re: [Module::Build] Problem building XS modules on AIX

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

James.FitzGibbon wrote:
> If I grep through the M::B source, the only platform that even touches
> EU::Mksymlists is Windows.  On UNIX platforms,
> including AIX, there is no procedure to generate that file.
> 
> Is there any simple way to make this work on AIX?  In looking at the
> v0.21 code, the Windows version of link_c
> calls prelink_c to generate the symbols, but prelink_c seems to make
> some very Windows-specific decisions
> about the names of the files to generate.
> 
> Any feedback appreciated.
> 

Hi James,

I'm the one who wrote Windows.pm. Can you post your perl Config.pm. 
Other than calling Mksymlists, it looks like we need to do some variable 
substitutions on some of the $Config variables, and I'll need to see 
Config.pm to know which ones.

Thanks,
Randy.

[Module::Build] Problem building XS modules on AIX

[James.FitzGibbon <Jam...@ta...>]

Recently I've been having problems getting M::B to build modules which
have
XS components on AIX.  I had initially thought that the problem lied
with
the upgrade from the 0.1x series to 0.2x, but after doing some research
I
beginning to think that XS modules could never be built on this
platform.

Here's what I get trying to build something like Pod::Coverage v0.12
(important bits have been hilighted)

[appserv:jfitzgi] ~/work/Pod-Coverage-0.12 (298) > ./Build
lib/Pod/Coverage/CountParents.pm ->
blib/lib/Pod/Coverage/CountParents.pm
lib/Pod/Coverage.pm -> blib/lib/Pod/Coverage.pm
lib/Pod/Coverage/ExportOnly.pm -> blib/lib/Pod/Coverage/ExportOnly.pm
lib/Pod/Coverage/Overloader.pm -> blib/lib/Pod/Coverage/Overloader.pm
lib/Pod/Coverage.xs -> lib/Pod/Coverage.c
cc_r -I/opt/3d/lib/perl5/5.8.0/aix-thread-multi/CORE -c -D_ALL_SOURCE
-D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=3D16384 -qnoansialias
-DUSE_NATIVE_DLOPEN -DNEED_PTHREAD_INIT -I/opt/3d/include -O -o
lib/Pod/Coverage.o lib/Pod/Coverage.c
ExtUtils::Mkbootstrap::Mkbootstrap('lib/Pod/Coverage')
lib/Pod/Coverage.bs -> blib/arch/auto/Pod/Coverage/Coverage.bs
ld -bhalt:4 -bM:SRE -bI:$(PERL_INC)/perl.exp -bE:$(BASEEXT).exp
-bnoentry -lpthreads -lc_r -L/opt/3d/lib -o
blib/arch/auto/Pod/Coverage/Coverage.so lib/Pod/Coverage.o
ld: 0706-003 Cannot find or read import file: $(PERL_INC)/perl.exp
        ld:accessx(): A file or directory in the path name does not
exist.
ld: 0706-004 Cannot find or read export file: $(BASEEXT).exp
        ld:accessx(): A file or directory in the path name does not
exist.
error building lib/Pod/Coverage.o from 'lib/Pod/Coverage.so' at
/home_dir/jfitzgi/myperl/lib/perl5/site_perl/5.8.0/Module/Build/Base.pm
line 1534, <File0000> line 18.
[appserv:jfitzgi] ~/work/Pod-Coverage-0.12 (299) >

Pod::Coverage switched from EU::MM to M::B between v0.11 (which we have
installed) and v0.12.
=20
Now if I look at an EU::MM created Makefile, both PERL_INC and BASEEXT
are given values (this is
from Lexical::Typeglob):

PERL_INC =3D /opt/3d/lib/perl5/5.8.0/aix-thread-multi/CORE
BASEEXT =3D Typeglob

The AIX linker uses -bI to import lists of symbols from a text file and
-bE to export lists of symbols to
a text file.  In this context I believe the invocation needs to see what
symbols are provided by the core
Perl libraries and then export the symbols that the target shared object
will contain.

Back to Lexical::Typeglob, there is a target to create the .exp files:

# --- MakeMaker dlsyms section:

dynamic :: Typeglob.exp


static :: Typeglob.exp


Typeglob.exp: Makefile.PL
    $(PERLRUN) -e 'use ExtUtils::Mksymlists; \
    Mksymlists("NAME" =3D> "Lexical::Typeglob", "DL_FUNCS" =3D> {  },
"FUNCLIST" =3D> [], "DL_VARS" =3D> []);'

If I grep through the M::B source, the only platform that even touches
EU::Mksymlists is Windows.  On UNIX platforms,
including AIX, there is no procedure to generate that file.

Is there any simple way to make this work on AIX?  In looking at the
v0.21 code, the Windows version of link_c
calls prelink_c to generate the symbols, but prelink_c seems to make
some very Windows-specific decisions
about the names of the files to generate.

Any feedback appreciated.

--=20
j.
=20
James FitzGibbon
TTS Distribution Development
612-375-2307
=20

Re: [Module::Build] (RFC) META.yml Specification Update

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

And here it is in pod format.

Re: [Module::Build] Alzabo / Module::Build Cygwin installation problem

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

On 11/14/2003 5:42 PM, Randy W. Sims wrote:
> There is still a problem to be worked out, but I'm not yet sure where 
> the problem is. Can you tell post your perl & Cwd version.
> 
> Dave, What versions of perl, Cwd, & M::B have you tested Alzabo with?
> 
> This problem doesn't seem directly related to Cygwin. It definately 
> should not be an error to 'use Cwd', so this has to be a problem in 
> M::B, Cwd, or perl. Right???
> 

Ok, this might in fact be a Cygwin problem. Cygwin & Cwd. The following 
produces the error "Usage: Cwd::cwd() at Module.pm line 6." under Cygwin 
perl 5.8.x, but not under MSWin32 perl 5.6.x & 5.8.x. Also if I change 
Cwd to Carp I get no error. Can anyone test to make sure this does not 
produce errors on any other systems?

Thanks,
Randy.

-----><8-----
# Module.pm
package Module;

sub new {
   my $p = shift;
   $p->cwd;
}

sub cwd {
   require Cwd;
   Cwd::cwd;
}

1;
-----><8-----

-----><8-----
# test.pl
package MyModule;
use Module;
use base 'Module';
use Cwd;

package main;
MyModule->new;
-----><8-----

Re: [Module::Build] Alzabo / Module::Build Cygwin installation problem

[Terrence B. <met...@ur...>]

Randy W. Sims wrote:

>
>
> There is still a problem to be worked out, but I'm not yet sure where 
> the problem is. Can you tell post your perl & Cwd version.
>
        ~/wares/MYTH $ perl -MCwd -e 'print $Cwd::VERSION'
2.06       
        ~/wares/MYTH $ perl -v

This is perl, v5.8.0 built for cygwin-multi-64int

Copyright 1987-2002, Larry Wall

Perl may be copied only under the terms of either the Artistic License 
or the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'.  If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.

        ~/wares/MYTH $ perl -MModule::Build -e 'print 
$Module::Build::VERSION'
0.21      

> Dave, What versions of perl, Cwd, & M::B have you tested Alzabo with?
>
> This problem doesn't seem directly related to Cygwin. It definately 
> should not be an error to 'use Cwd', so this has to be a problem in 
> M::B, Cwd, or perl. Right???
>
> >> I can run linux inside a VM
>
>>> Ware virtual machine faster than Cygwin (no exageration).
>>>
>> hmm, you have me licking my lips. A real Linux installation but with 
>> the tcp/ip ease-of-installation of Windows???
>> and no quirky compile problems because everybody develops and tests 
>> on Linux??? hmm....
>>
>
> It's a great product. I wouldn't be without it. I think they have a 30 
> day fully functional trial version.
>
> Regards,
> Randy.
>
>

Re: [Module::Build] Alzabo / Module::Build Cygwin installation problem

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

On Fri, 14 Nov 2003, Randy W. Sims wrote:

> Dave, What versions of perl, Cwd, & M::B have you tested Alzabo with?

I've tested Alzabo with Perl 5.6.1 & 5.8.[01], usually using the latest
Module::Build.  I don't know what versions oCwd I used.

However, I realized that I don't actually use Cwd in the build code any
more so I removed it.

> This problem doesn't seem directly related to Cygwin. It definately
> should not be an error to 'use Cwd', so this has to be a problem in
> M::B, Cwd, or perl. Right???

I assume so.


-dave

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

Re: [Module::Build] Alzabo / Module::Build Cygwin installation problem

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

Terrence Brannon wrote:
> Randy W. Sims wrote:
> 
>> Ok. Sorry to get back so late on this. I tried yesterday but got 
>> frustrated with Cygwin trying to install PostgreSQL and stuff...
>>
> Postgresql on Cygwin is a snap. Jason Tishler put together the 
> Postgresql package and here is his install instructions:

<snip usefull info>

Thanks.

>> Anyway, I trace this to Alzabo-0.80/inc/Alzabo/Build.PL which does a 
>> 'use Cwd' which apparently conflicts with M::B's override of cwd. Can 
>> you comment out that use declaration and post your results.
> 
> 
> a different use Cwd must be commented out.
> 
<snip>

There is still a problem to be worked out, but I'm not yet sure where 
the problem is. Can you tell post your perl & Cwd version.

Dave, What versions of perl, Cwd, & M::B have you tested Alzabo with?

This problem doesn't seem directly related to Cygwin. It definately 
should not be an error to 'use Cwd', so this has to be a problem in 
M::B, Cwd, or perl. Right???

 >> I can run linux inside a VM
>> Ware virtual machine faster than Cygwin (no exageration).
>>
> hmm, you have me licking my lips. A real Linux installation but with the 
> tcp/ip ease-of-installation of Windows???
> and no quirky compile problems because everybody develops and tests on 
> Linux??? hmm....
> 

It's a great product. I wouldn't be without it. I think they have a 30 
day fully functional trial version.

Regards,
Randy.

Re: [Module::Build] Alzabo / Module::Build Cygwin installation problem

[Terrence B. <met...@ur...>]

Randy W. Sims wrote:

> Ok. Sorry to get back so late on this. I tried yesterday but got 
> frustrated with Cygwin trying to install PostgreSQL and stuff...
>
Postgresql on Cygwin is a snap. Jason Tishler put together the 
Postgresql package and here is his install instructions:

http://www.tishler.net/jason/software/postgresql/

And I have a little script that does it for me:

        ~/bin/psql $ cat START_PG
#!/bin/sh -x

rm /usr/share/postgresql/data/postmaster.pid
ipc-daemon2 &
postmaster -i -D /usr/share/postgresql/data &
        ~/bin/psql $

> Anyway, I trace this to Alzabo-0.80/inc/Alzabo/Build.PL which does a 
> 'use Cwd' which apparently conflicts with M::B's override of cwd. Can 
> you comment out that use declaration and post your results.

a different use Cwd must be commented out. I did a recursive search for 
all such uses:

cd /home/metaperl/.cpan/build/Alzabo-0.80/
find . -type f -print0 | xargs -0 -e grep -n Cwd
./Build.PL:5:#use Cwd;
./inc/Alzabo/Build.pm:10:#use Cwd;
./Makefile.PL:11:#        require Cwd;
./Makefile.PL:16:        my $cwd = Cwd::cwd();
./t/lib/Alzabo/Test/Utils.pm:6:#use Cwd ();
./t/lib/Alzabo/Test/Utils.pm:58:    my $cwd = Cwd::cwd();

and commented them all out. Now the test suite passes and I am 
installing Alzabo-0.80. I am a happy man.

Many thanks to Randy for his help.

>
> When I do this it goes a little further listing a bunch of 
> prerequisites I'm not going to install unless there are further 
> problems because Cygwin is extremely slow. I can run linux inside a VM 
> Ware virtual machine faster than Cygwin (no exageration).
>
hmm, you have me licking my lips. A real Linux installation but with the 
tcp/ip ease-of-installation of Windows???
and no quirky compile problems because everybody develops and tests on 
Linux??? hmm....

[Module::Build] (RFC) (PATCH) META.yml Specification Update

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

Ok. So, I've gone over the spec and referenced this thread and my 
archives of past meta discusions on module-authors, and I've come up 
with a preliminary patch for Ken and anyone else interested. This is a 
patch against <http://module-build.sourceforge.net/META-spec.html> which:

* Added more YAML rationale articles.
* Fixed existing link to YAML discussion thread to point to new 
<http://nntp.x.perl.org/group/> site.
* Added and deprecated the "private" field.
* Added "abstract", "configure", "requires_os", "excludes_os", and 
"no_index" fields.
* Bumped version.

Comments and suggestions?

Randy.

Why YAML. (was Re: [Module::Build] Re: How to indicate a dependency in my module)

[Michael G S. <sc...@po...>]

First, I'd like to address people's concern over the format of the META 
file.  Module users and 99% of module authors have nothing to be concerned
about.   Most folks shouldn't even know the thing exists.

Module::Build has been generating and using META.yml since nearly the 
beginning.  MakeMaker has been generating META.yml automaticly for its 
authors since last July.  CPAN is now full of META.yml files.  5.8.2 comes
with a META.yml file.  If you're just now noticing META.yml then we've done 
our job.  It could have been written in esperanto with FoxPro for all it 
matters to the end user.

If we do our job right, most people should never have to directly read or
write a META.yml file.  Its generated automaticly by MakeMaker and 
Module::Build and module tools (PAUSE, search.cpan.org, CPANPLUS, etc...)
use it without your intervention.

The only people who should be concerned are authors of these tools and folks
involved in gethering CPAN statistics.  Even module authors need not know
about it as its automaticly generated when the run "make dist" or "Build dist".

I say this because every few months someone notices META.yml and asks "Why 
did we use YAML and not X?" which starts the same debate all over again with 
the same answers.  We need a FAQ.


To address the "I don't want to learn another data format, why can't we
just use Perl?" issue.  With YAML, you don't have to learn the data format.
Let's look at how you'd generate a META file with Data::Dumper.

	use Data::Dumper;
	$Data::Dumper::Terse = 1;
	my $meta = { name => "Foo::Bar", version => 1.23 };
	open(META, ">META.perl");
	print META Dumper($meta);
	close META;

And the equivalent with YAML.pm.

	use YAML qw(DumpFile);
	my $meta = { name => "Foo::Bar", version => 1.23 };
	DumpFile("META.yml", $meta);

And now reading back in the Perl version.

	my $meta = do 'META.perl';
	print $meta->{version};

And the YAML version.

	use YAML qw(LoadFile);
	my $meta = LoadFile("META.yml");
	print $meta->{version};

YAML's data model is so similar to Perl's (hashes, scalars, lists) that the
data you put in and take out is almost indistinguishable from Data::Dumper.
All that's different is the transient storage medium.  So even if you wanted
to roll your own META.yml file you never have to learn YAML!  The only
prereq is to have YAML.pm installed.

And, finally, because I know someone's going to ask about the YAML.pm
prereq, YAML.pm is not required by MakeMaker.  It generates META.yml by
hand and doesn't use it for anything.  For Module::Build its an optional 
prereq.

I hope that covers the bases.


Now to address Phil's specific concerns.


On Wed, Nov 12, 2003 at 10:25:00AM -0500, Phi...@mo... wrote:
> OK, maybe I'm missing a LOT of context here, 'cause I haven't been
> agressively keeping up with this mailing list, but the security hole
> argument seems a bit odd.
> 
> These META.yml files we're refering to -- these are meta data for
> managing the build process, files that will be distributed along with
> the tarballs we upload to CPAN, right?  

Module::Build might use META.yml a little in its build process, but its not
a requirement.  MakeMaker can't even read META.yml.  Its not META.yml's 
primary purpose to be used to build a module.  Its just turning out
to be really damned useful. :)

The primary purpose of META.yml is to supply module meta data that we'd
normally have to go crawling around in the code to get.  Like $VERSION
(to get this you have to eval a line of the module) and its prerequisites
(to get that you have to run the Makefile.PL and parse the resulting 
Makefile).  

It also contains intangables like what license the code is distributed
under that you'd normally have to go groping around in the POD to try and
figure out.

File lists in META.yml are currently used as hints to the PAUSE indexer so
it can better determine what to index.  For example, 5.8.2's META.yml
contains a listing "private" (which I think is changing to noindex) to tell
PAUSE not to index these files/directories in the module list.  In this case
its because these are dual-life modules that also have CPAN versions.


> So, if I understand this correctly, you're worried about the build
> process eval'ing the contents of a file I sent you.  Hmm.

No, the case where security enters is when someone is grab CPAN meta 
information.  For example, PAUSE, CPAN search sites, anyone trying to do 
CPAN statistics, anyone trying to determine the prerequisites of a module, 
etc...  

CPAN statistics gathering currently involves running large amounts of 
untrusted code.  MakeMaker's parse_version() literally pulls a line of code 
out of the module and evals it.  To determine the prerequisties you have to 
run the Makefile.PL which, as Mark-Jason Dominus once demonstrated with
Memoize (I think it was) could contain rm -rf /.

Of course, when you build and install a module you are trusting that it
won't do anything naughty.  However, a user typically builds and installs
*a* module.  Or a set of modules, picked either by hand or because they're
a prerequisite of a module they picked by hand (thus, the author picked
by hand).  This selectiveness prevents some random hacker from uploading a 
module with an rm -rf in it.  Nobody will bother to install it because 
nobody will know about it.  Security through module obscurity. :)  For
better or worse, this is CPAN's ad-hoc "web of trust" model of security.

In contrast, CPAN statistics gathering usually involves *all* the modules 
on CPAN.  In this case, it will pick up RHACKER's module and blissfully run 
its Makefile.PL and $VERSION line causing who knows what havoc.  We shouldn't
have to set up a chroot jail (as PAUSE does) just to gether some
stats.

Since META.yml is automaticly generated by both Module::Build and MakeMaker,
CPAN is rapidly populating with META.yml files and code scaping for meta-data
will mostly disappear closing one of the big backdoors in CPAN.


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
IIRC someone observed that they couldn't name identifiers in Ethiopian, 
because there was an Ethiopian character similar in function to _ which 
wasn't in \w
        -- Nicholas Clark demonstrates that the Internet works
           in <200...@pl...>

Re: [Module::Build] Alzabo / Module::Build Cygwin installation problem

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

On 11/11/2003 4:32 AM, Terrence Brannon wrote:
> Randy W. Sims wrote:
> 
>> Terrence Brannon wrote:
>>
>>> Thanks for all the work to get Module::Build functional under Cygwin. 
>>> I was not able to run the more-recent versions of Alzabo until this 
>>> happened. However, attempting to install Alzabo-0.80 yields an error 
>>> which appears to be coming from Module::Build. I just installed 
>>> Cygwin 3 days ago, so it is definitely the latest version.
>>>
>>
>> It will be at least tomorrow before I can try this out under Cygwin. 
>> What happens if you build/test this manually with verbose=1?
> 
> 
> There is no more output than when it was ran by default, assuming I did 
> things correctly:
> 
>        ~ $ perl -MCPAN -e 'get Alzabo'
> 
>        ~ $         ~ $ cd .cpan/build
>        ~/.cpan/build $ cd Alzabo-0.80/
>        ~/.cpan/build/Alzabo-0.80 $ ls
> Build.PL  LICENSE   Makefile.PL  TODO  install_helpers    t
> Changes   MANIFEST  README     eg    lib
> INSTALL   META.yml  SIGNATURE     inc   mason
>        ~/.cpan/build/Alzabo-0.80 $ perl Makefile.PL verbose=1
> perl Build.PL verbose=1
> 
> Please select a root directory for Alzabo (schema files will be stored
> under this root.
>  Alzabo root? [/home/metaperl/alzaobo] /home/metaperl/alzabo
> 
> The following questions pertain to optional features of Alzabo.  These
> questions help the installer determine what additional system checks
> to perform.
> 
> 
> To use the MySQL driver requires DBD::mysql (2.1017).
>  Do you want to use the MySQL driver? [no]
> no
> 
> To use the PostgreSQL driver requires DBD::Pg (1.13).
>  Do you want to use the PostgreSQL driver? [yes]
> yes
> 
> The information from the following questions are used solely for
> testing the pieces of Alzabo that require a real database for proper
> testing.
>  Do tests with Postgres RDBMS? [yes]
> yes
> 
> Please provide a username that can be used to connect to the Postgres
> RDBMS?  This user must have the ability to create a new
> database/schema.
>  Username?  metaperl
>  Password for metaperl?
> 
> What host is the Postgres RDBMS located on.  Press enter to skip this if
> the database server is located on the localhost or can be determined
> in another way (for example, Oracle can use TNS to find the database).
>  Host?
> 
> What port is the Postgres RDBMS located on.  Press enter to skip this.
>  Port?
> 
> Please provide a database name that can be used for testing.  A
> database/schema with this name will be created and dropped during the
> testing process.
>  Database name? [test_alzabo_pg]
> test_alzabo_pg
> Usage: Cwd::cwd() at /usr/lib/perl5/site_perl/5.8.0/Module/Build/Base.pm 
> line 84.
> Couldn't run Build.PL:  at 
> /usr/lib/perl5/site_perl/5.8.0/Module/Build/Compat.pm line 120.
>        ~/.cpan/build/Alzabo-0.80 $
> 
> 

Ok. Sorry to get back so late on this. I tried yesterday but got 
frustrated with Cygwin trying to install PostgreSQL and stuff...

Anyway, I trace this to Alzabo-0.80/inc/Alzabo/Build.PL which does a 
'use Cwd' which apparently conflicts with M::B's override of cwd. Can 
you comment out that use declaration and post your results.

When I do this it goes a little further listing a bunch of prerequisites 
I'm not going to install unless there are further problems because 
Cygwin is extremely slow. I can run linux inside a VM Ware virtual 
machine faster than Cygwin (no exageration).

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

Re: [Module::Build] Re: How to indicate a dependency in my module

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

On Wed, Nov 12, 2003 at 04:11:45PM +0000, Sam Vilain wrote:
> On Tue, 11 Nov 2003 02:29, Michael G Schwern wrote;
> 
>   > YAML was chosen because its human readable and writable, its data
>                                 ^^^^^              ^^^^^^^^^
> So long as you're a FREAK who likes INDENTING and WHITESPACE to
> signify STRUCTURE.
> 
> Is it any surprise that YAML is supported by PYTHON?!

no, not at ALL

but GIVEN that XS also treats INDENTING and WHITESPACE significantly,
it is STRANGE that there are no YAML modules for perl written in XS.

[although I believe that Ingy is working on something]

Nicholas Clark

Re: [Module::Build] Re: How to indicate a dependency in my module

[Sam V. <sa...@vi...>]

On Tue, 11 Nov 2003 02:29, Michael G Schwern wrote;

  > YAML was chosen because its human readable and writable, its data
                                ^^^^^              ^^^^^^^^^
So long as you're a FREAK who likes INDENTING and WHITESPACE to
signify STRUCTURE.

Is it any surprise that YAML is supported by PYTHON?!

</topicalButTechnicallyVoidRantIgnoringTheObviousReplyForComicalValue>
-- 
Sam Vilain, sa...@vi...

  If you cant learn to do it well, learn to enjoy doing it badly.
ASHLEIGH BRILLIANT

Re: [Module::Build] Re: How to indicate a dependency in my module

[<Phi...@mo...>]

>>>>> "Chris" == Christopher Hicks <ch...@ch...> writes:

>> So, if I understand this correctly, you're worried about the build
>> process eval'ing the contents of a file I sent you.  Hmm.
>> 
>> OK, why is that anymore of a concern for eval'ing the perl module I
>> also distributed, too?  Isn't that just as big a security hole?  

Chris> There are any number of reasons I may be interested in
Chris> examining your module for extracting documentation and
Chris> dependancies without actually running a single line of your
Chris> code.  The safer we make this sort of thing the more things
Chris> like search.cpan.org and various more recent alternatives we'll
Chris> have.

Ok, that makes sense... Thanks.  I hadn't really though about using
this data outside of the build process.

Re: [Module::Build] Re: How to indicate a dependency in my module

[Christopher H. <ch...@ch...>]

On Wed, 12 Nov 2003 Phi...@mo... wrote:
> So, if I understand this correctly, you're worried about the build
> process eval'ing the contents of a file I sent you.  Hmm.
> 
> OK, why is that anymore of a concern for eval'ing the perl module I
> also distributed, too?  Isn't that just as big a security hole?  

There are any number of reasons I may be interested in examining your
module for extracting documentation and dependancies without actually
running a single line of your code.  The safer we make this sort of thing
the more things like search.cpan.org and various more recent alternatives
we'll have.

-- 
</chris>

> What the US needs is a Manhattan Project for alternative energy to oil.
They should threaten their enemies with windmills?
		- BabyDave on /.

Re: [Module::Build] Re: How to indicate a dependency in my module

[<Phi...@mo...>]

OK, maybe I'm missing a LOT of context here, 'cause I haven't been
agressively keeping up with this mailing list, but the security hole
argument seems a bit odd.

These META.yml files we're refering to -- these are meta data for
managing the build process, files that will be distributed along with
the tarballs we upload to CPAN, right?  

So, if I understand this correctly, you're worried about the build
process eval'ing the contents of a file I sent you.  Hmm.

OK, why is that anymore of a concern for eval'ing the perl module I
also distributed, too?  Isn't that just as big a security hole?  

Or how about the test suites?  If I want to deploy malicious code in
my CPAN upload, I can just drop the evil code into my test suite, and
when you type make tes, I take over your world.

Am I missing something?  Because I also am loath to accept yet another
file format, personally, and I would also prefer to keep my
configuration data written in perl as well.

And if we're talking about the perl build process, what's wrong with a
perl-specific configuration mechanism?

>>>>> "Michael" == Michael G Schwern <Michael> writes:

Michael> In a nutshell: eval()ing the Perl structure back in is a major security hole.
Michael> Part of the point of META.yml is to avoid having to run any foreign code to
Michael> figure out module meta information.

Michael> To review (maybe this should be in a FAQ somewhere).

Michael> Data::Dumper/Perl code - Insecure (you have to eval it).  Perl specific.
Michael> Storable     - Not human readable.  Format changes slightly from version to
Michael> version.  Perl specific.
Michael> XML          - Overkill.  Ugly.  Requires translation between Perl data
Michael> model (hashes, lists, scalars) and XML's (trees).
Michael> Difficult to read and write by humans.

Michael> YAML was chosen because its human readable and writable, its data 
Michael> structures closely match those of Perl (ie. scalars, hashes and arrays),
Michael> it can be read without being eval'd, executable code cannot be hidden in
Michael> it and, as a bonus, its not Perl specific.

Michael> YAML's basic formatting is a structure we're already familiar with and tend
Michael> to use when writing ad-hoc data structures (ie. key: value).
Michael> Indentation as structure we're already more than comfortable with (ie. 
Michael> indented source code) so readers of YAML should have no problem. 
Michael> The less obvious features of YAML shouldn't be necessary for most META.yml
Michael> files.

Michael> Because YAML's data model closely matches that of Perl, writers of META.yml 
Michael> simply need to construct a mirroring Perl structure and let YAML dump it
Michael> out.  Its the closest thing to "Data::Dumper evaling" available.


Michael> -- 
Michael> Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
Michael> I'll tell you what beats voodoo every time, a big ass knife.
Michael> -- "Overkill" Battlebot driver

Re: [Module::Build] Alzabo / Module::Build Cygwin installation problem

[Terrence B. <met...@ur...>]

Randy W. Sims wrote:

> Terrence Brannon wrote:
>
>> Thanks for all the work to get Module::Build functional under Cygwin. 
>> I was not able to run the more-recent versions of Alzabo until this 
>> happened. However, attempting to install Alzabo-0.80 yields an error 
>> which appears to be coming from Module::Build. I just installed 
>> Cygwin 3 days ago, so it is definitely the latest version.
>>
>
> It will be at least tomorrow before I can try this out under Cygwin. 
> What happens if you build/test this manually with verbose=1?

There is no more output than when it was ran by default, assuming I did 
things correctly:

        ~ $ perl -MCPAN -e 'get Alzabo'

        ~ $         ~ $ cd .cpan/build
        ~/.cpan/build $ cd Alzabo-0.80/
        ~/.cpan/build/Alzabo-0.80 $ ls
Build.PL  LICENSE   Makefile.PL  TODO  install_helpers    t
Changes   MANIFEST  README     eg    lib
INSTALL   META.yml  SIGNATURE     inc   mason
        ~/.cpan/build/Alzabo-0.80 $ perl Makefile.PL verbose=1
perl Build.PL verbose=1

Please select a root directory for Alzabo (schema files will be stored
under this root.
  Alzabo root? [/home/metaperl/alzaobo] /home/metaperl/alzabo

The following questions pertain to optional features of Alzabo.  These
questions help the installer determine what additional system checks
to perform.


To use the MySQL driver requires DBD::mysql (2.1017).
  Do you want to use the MySQL driver? [no]
no

To use the PostgreSQL driver requires DBD::Pg (1.13).
  Do you want to use the PostgreSQL driver? [yes]
yes

The information from the following questions are used solely for
testing the pieces of Alzabo that require a real database for proper
testing.
  Do tests with Postgres RDBMS? [yes]
yes

Please provide a username that can be used to connect to the Postgres
RDBMS?  This user must have the ability to create a new
database/schema.
  Username?  metaperl
  Password for metaperl? 


What host is the Postgres RDBMS located on.  Press enter to skip this if
the database server is located on the localhost or can be determined
in another way (for example, Oracle can use TNS to find the database).
  Host? 


What port is the Postgres RDBMS located on.  Press enter to skip this.
  Port? 


Please provide a database name that can be used for testing.  A
database/schema with this name will be created and dropped during the
testing process.
  Database name? [test_alzabo_pg]
test_alzabo_pg
Usage: Cwd::cwd() at /usr/lib/perl5/site_perl/5.8.0/Module/Build/Base.pm 
line 84.
Couldn't run Build.PL:  at 
/usr/lib/perl5/site_perl/5.8.0/Module/Build/Compat.pm line 120.
        ~/.cpan/build/Alzabo-0.80 $

Re: [Module::Build] Re: How to indicate a dependency in my module

[Michael G S. <sc...@po...>]

On Mon, Nov 10, 2003 at 05:42:03PM -0800, Terrence Brannon wrote:
> >Thinking more about this, I guess META.yml would need to provide a 
> >little more info to a configure module. Would something like the 
> >following work?
> 
> It's probably too late, but I am not keen on YAML. What is wrong with 
> pure Perl configuration information? 

In a nutshell: eval()ing the Perl structure back in is a major security hole.
Part of the point of META.yml is to avoid having to run any foreign code to
figure out module meta information.

To review (maybe this should be in a FAQ somewhere).

Data::Dumper/Perl code - Insecure (you have to eval it).  Perl specific.
Storable     - Not human readable.  Format changes slightly from version to
               version.  Perl specific.
XML          - Overkill.  Ugly.  Requires translation between Perl data
               model (hashes, lists, scalars) and XML's (trees).
               Difficult to read and write by humans.

YAML was chosen because its human readable and writable, its data 
structures closely match those of Perl (ie. scalars, hashes and arrays),
it can be read without being eval'd, executable code cannot be hidden in
it and, as a bonus, its not Perl specific.

YAML's basic formatting is a structure we're already familiar with and tend
to use when writing ad-hoc data structures (ie. key: value).
Indentation as structure we're already more than comfortable with (ie. 
indented source code) so readers of YAML should have no problem. 
The less obvious features of YAML shouldn't be necessary for most META.yml
files.

Because YAML's data model closely matches that of Perl, writers of META.yml 
simply need to construct a mirroring Perl structure and let YAML dump it
out.  Its the closest thing to "Data::Dumper evaling" available.


-- 
Michael G Schwern        sc...@po...  http://www.pobox.com/~schwern/
I'll tell you what beats voodoo every time, a big ass knife.
	-- "Overkill" Battlebot driver

[Module::Build] Re: How to indicate a dependency in my module

[Terrence B. <met...@ur...>]

Randy W. Sims wrote:

>
> Thinking more about this, I guess META.yml would need to provide a 
> little more info to a configure module. Would something like the 
> following work?

It's probably too late, but I am not keen on YAML. What is wrong with 
pure Perl configuration information? YAML is touchy about how it is 
formatted. Perl programmers will be reading this information and all 
Perl programmers already know Perl, so why fix what is not broken? Why 
force them to learn YAML?

[Module::Build] Re: How to indicate a dependency in my module

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

Randy W. Sims wrote:

> darren chamberlain wrote:
> 
>> * Randy W. Sims <RandyS at ThePierianSpring.org> [2003-11-10 15:49]:
>>
>>> Also, as I noted in the AFS thread the other day, this info should be 
>>> written in META.yml so that cpan-testers can determine 
>>> programatically whether a module should be tested. Info like required 
>>> non-perl packages and libraries, whether the build/test/install 
>>> process is interactive (or scriptable) or automated, and whether it 
>>> runs only on certain OSs or excludes certain OSs.
>>
>>
>>
>> I like this idea; I must have not been paying close enough attention to
>> your other message.  How could it be done, though?  I can see a simple
>> exression -> expected value scheme working for a lot of things (e.g.,
>> "$^0 eq 'MacOS'", or "eval { getpwuid };" ), but how would things like
>> AFS be detectible?
>>
>> (darren)
>>
> 
> I'm making this up as I go, but I'm thinking that META.yml would just 
> contain a list of required packages and possibly the minimum version 
> required. Initially, that should be enough to flag it for cpan-testers. 
> Ideally, there would be a module (Module::Build::Configure) that could 
> try to determine whether those requirements are satisfied for a 
> particular system. This could be done by a which/where like routine to 
> search for binaries, looking for config files, analyzing the install log 
> of package managers like rpm, dpkg, etc.
> 
> In addition for larger packages like Apache there could be, for example 
> an Module::Build::Configure::Apache module that provided other usefull 
> info about that package like paths and other configuration info that 
> might be usefull to module authors.
> 
> Randy.
> 

Thinking more about this, I guess META.yml would need to provide a 
little more info to a configure module. Would something like the 
following work?

# Sequence of $^O values to include/exclude certains OSs
# One of the following as apropriate:
requires_os: *
excludes_os: MSWin32

# extra-perl requirements
# The has_* keys may map to a function call
# with it's values as arguments. If all calls return
# success the requirement is considered to be satisfied.
required_packages:
   - killerapp:
     version: 4.0
     has_program:
       - foo
       - bar
     has_lib:
       - a
       - z
   - libintl:
     version: 2

# One of auto/interactive/scriptable for cpan-testers
# to know how to setup testing
testing_mode: auto