Re: Latest MM and ExtUtils::ParseXS

2003-04-04 Thread Michael G Schwern
On Mon, Mar 31, 2003 at 08:27:17PM -0600, Dave Rolsky wrote:
 Well, it found ExtUtils/xsubpp in the new location, which is good.  But
 then it expected to find a typemap file in the same location, which is
 bad.
 
 I'm not sure what the right solution is.  Either MM has to look for these
 separately, or EU::ParseXS should install a typemap file.

Ewww, typemap files.  Fear.  Flee.

When I first shipped MakeMaker as a CPAN module, I'd included the
bleadperl typemap file along with it.  I was told not to do that because its
very version specific.

Hmmm.  I guess I'll just decopule the two.  I'll give the typemap location
its own macro but only look for it in the perl core directory.


-- 
Beer still cheaper than crack!


gmake/gcc

2003-04-04 Thread adam welch
I am sure you have heard this refrain before, but it would be hugely 
helpful if gmake/gcc were supported as VC++ is getting quite pricey.  
Anyhoo, maybe Module::Build will take care of this???

Regards,
Adam Welch



Re: Latest MM and ExtUtils::ParseXS

2003-04-04 Thread Ken Williams
On Friday, April 4, 2003, at 04:06  AM, Michael G Schwern wrote:

On Mon, Mar 31, 2003 at 08:27:17PM -0600, Dave Rolsky wrote:
Well, it found ExtUtils/xsubpp in the new location, which is good.  
But
then it expected to find a typemap file in the same location, which is
bad.

I'm not sure what the right solution is.  Either MM has to look for 
these
separately, or EU::ParseXS should install a typemap file.
Ewww, typemap files.  Fear.  Flee.
Yeah, I certainly don't pretend to understand typemaps, though I've 
been able to get good use out of them.


When I first shipped MakeMaker as a CPAN module, I'd included the
bleadperl typemap file along with it.  I was told not to do that 
because its
very version specific.

Hmmm.  I guess I'll just decopule the two.  I'll give the typemap 
location
its own macro but only look for it in the perl core directory.

That sounds like the right thing to do.  No need to couple 'em.

 -Ken



Re: gmake/gcc

2003-04-04 Thread Michael G Schwern
On Thu, Apr 03, 2003 at 04:04:21PM -0800, adam welch wrote:
 I am sure you have heard this refrain before, but it would be hugely 
 helpful if gmake/gcc were supported as VC++ is getting quite pricey.  
 Anyhoo, maybe Module::Build will take care of this???

MakeMaker does support gcc on Win32, or at least there's some special cases
in there for it.  Whether or not it works I have no idea as I've never
seen a gmake/gcc/Win32/MakeMaker bug report...


PS That's your cue.


Fwd: MakeMaker busted with dmake

2003-04-04 Thread Michael G Schwern
Forwarding for pondering.


- Forwarded message from Abe Timmerman [EMAIL PROTECTED] -

From: Abe Timmerman [EMAIL PROTECTED]
Date: Sat, 5 Apr 2003 02:18:46 +0200
To: Michael G Schwern [EMAIL PROTECTED]
Subject: Re: [ANNOUNCE] ExtUtils::MakeMaker 6.06_02 alpha
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
User-Agent: KMail/1.4.3
In-Reply-To: [EMAIL PROTECTED]
Organization: ztreet

Op een frisse lentedag (Saturday 05 April 2003 01:06), schreef Michael G 
Schwern:

 On Fri, Apr 04, 2003 at 01:19:11PM +0200, Abe Timmerman wrote:
   Could you give the latest MakeMaker snapshot a try from makemaker.org?
 
  Is that 6.10_01?

 Yep.

   I think I've fixed the dmake problems.
 
  c:\opt\perl590\bin\perl -Mblib t\basic.t
  1..48
  not ok 1 - chdir'd to Big-Dummy
  # Failed test (t\basic.t at line 62)
  # chdir failed: No such file or directory
  Can't open perl script Makefile.PL: No such file or directory

 t/00setup_dummy.t has to be run before basic.t will work.  I'd suggest
 just running the full 'dmake test' process anyway.  Other things may have
 broken since the last time you ran it, and just on general principles.

Ah, I see. I did run dmake test first and reran t/basic.t separate because 
it failed, my mistake.

Attached is the full dmake test output (incl. stderr)

Good luck,

Abe
-- 
NI-S All in all not one of my better bits of code.
EINSUFFICIENTPARANOIA?

Remember, just because you don't believe that everyone is out to get

you, it doesn't actually mean that they are not.
-- Nicholas Clark on p5p @ 20020522

C:\opt\perl590\bin\perl.exe -Ilib -MExtUtils::Command -e cp bin/instmodsh 
blib\script\instmodsh
pl2bat.bat blib\script\instmodsh
C:\opt\perl590\bin\perl.exe -Ilib -MExtUtils::Command::MM -e test_harness(0, 
'blib\lib', 'blib\arch') t\00compile.t t\00setup_dummy.t t\backwards.t t\basic.t 
t\Command.t t\hints.t t\INST.t t\INST_PREFIX.t t\Install.t t\Installed.t t\Liblist.t 
t\Manifest.t t\Mkbootstrap.t t\MM_BeOS.t t\MM_Cygwin.t t\MM_NW5.t t\MM_OS2.t 
t\MM_Unix.t t\MM_VMS.t t\MM_Win32.t t\oneliner.t t\Packlist.t t\prefixify.t 
t\problems.t t\prompt.t t\split_command.t t\testlib.t t\VERSION_FROM.t 
t\writemakefile_args.t t\zz_cleanup_dummy.t
t\00compile.ok
27/54 skipped: Test::Pod not installed
t\00setup_dummy.ok
t\backwards.ok
t\basic.Can't find string terminator @ anywhere before EOF at -e 
line 1.
dmake.exe:  Error code 255, while making 'ppd'
# Failed test (t\basic.t at line 101)
#  got: '65280'
# expected: '0'
# Failed test (t\basic.t at line 106)
#   ''
# doesn't match '(?m-xis:^SOFTPKG NAME=Big-Dummy VERSION=0,01,0,0)'
# Failed test (t\basic.t at line 108)
#   ''
# doesn't match '(?m-xis:^\s*TITLEBig-Dummy/TITLE)'
# Failed test (t\basic.t at line 109)
#   ''
# doesn't match '(?m-xis:^\s*ABSTRACTTry our hot dog's/ABSTRACT)'
# Failed test (t\basic.t at line 111)
#   ''
# doesn't match '(?m-xis:^\s*AUTHORMichael G Schwern lt;[EMAIL 
PROTECTED]gt;/AUTHOR)'
# Failed test (t\basic.t at line 114)
#   ''
# doesn't match '(?m-xis:^\s*IMPLEMENTATION)'
# Failed test (t\basic.t at line 115)
#   ''
# doesn't match '(?m-xis:^\s*DEPENDENCY NAME=strict VERSION=0,0,0,0 /)'
# Failed test (t\basic.t at line 117)
#   ''
# doesn't match '(?m-xis:^\s*OS NAME=MSWin32 /)'
# Failed test (t\basic.t at line 119)
#   ''
# doesn't match '(?m-xis:^\s*ARCHITECTURE NAME=MSWin32-x86-multi-thread /)'
# Failed test (t\basic.t at line 121)
#   ''
# doesn't match '(?m-xis:^\s*CODEBASE HREF= /)'
# Failed test (t\basic.t at line 122)
#   ''
# doesn't match '(?m-xis:^\s*/IMPLEMENTATION)'
# Failed test (t\basic.t at line 123)
#   ''
# doesn't match '(?m-xis:^\s*/SOFTPKG)'
dmake.exe:  makefile:  line 669:  Warning -- Macro `TEST_VERBOSE' cannot be redefined
Can't find string terminator @ anywhere before EOF at -e line 1.
dmake.exe:  Error code 255, while making 'doc_site_install'
# Failed test (t\basic.t at line 140)
#  got: '65280'
# expected: '0'
# Installing dummy-install\lib\Big\Dummy.pm
# Installing dummy-install\lib\Big\Liar.pm
# Writing dummy-install\lib\auto\Big\Dummy\.packlist
# Failed test (t\basic.t at line 153)
dmake.exe:  makefile:  line 69:  Warning -- Macro `PREFIX' cannot be redefined
Can't find string terminator @ anywhere before EOF at -e line 1.
dmake.exe:  Error code 255, while making 'doc_site_install'
# Failed test (t\basic.t at line 160)
#  got: '65280'
# expected: '0'
# Installing elsewhere\lib\Big\Dummy.pm
# Installing elsewhere\lib\Big\Liar.pm
# Writing elsewhere\lib\auto\Big\Dummy\.packlist
# Failed test (t\basic.t at line 170)
Can't find string terminator @ anywhere 

Re: [PATCH MM 6.06_05ish] PERL_ARCHIVE tweak for VMS

2003-04-04 Thread Michael G Schwern
On Tue, Apr 01, 2003 at 10:54:13PM -0600, Craig A. Berry wrote:
 At 11:48 PM -0600 3/31/03, Craig A. Berry wrote:
 For some reason older versions of MakeMaker never actually got the
 initialization of the PERL_ARCHIVE macro into the descrip.mms on VMS.
 The new version does, but it's value is wrong.  The patch here fixes
 that.
 
 Well, actually, that wasn't quite right.  We should never reference
 the PERLSHR logical name in this context.  During a core build, if it
 exists it will refer to an installed Perl, not the one we're
 building.  When building an extension against an installed Perl, it
 doesn't buy us anything over PERL_SRC because of the way perl_root
 works on VMS.  So, here's my second and hopefully final attempt at this.

Ok, its in the snapshot.  Thanks.


-- 
1 4m 4 31134 h4X0R \/\/H1 15 /\/\1 5cR33N B100??!?!?!?