Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <3B82D612.40201@ece.gatech.edu>
Date: Tue, 21 Aug 2001 17:43:46 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: gp AT familiehaase DOT de
CC: cygwin-apps AT cygwin DOT com
Subject: Re: perl, second shot (was: Re: first shot perl)
References: <3B82D37D DOT 24205 DOT FBBF7EA AT localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Gerrit P. Haase wrote:

> Charles Wilson schrieb am 2001-08-21, 12:11:
> 
> 
>>>Oops, seems to be a problem with the timestamp-trick. The last build was 
>>>with multiplicity. Thats the reason why the tarball is so big...
>>>I build with multiplicity because i got a lot of more errors during tests 
>>>without it.
>>>
>>
>>What sort of errors?  In the past we were able to get 100 percent 
>>compliance with test suite and did NOT have to build with multiplicity.
>>
>>
> 
> Yes I think it does make no difference. I would prefer to build with, if
> it is not a problem with win98?


I don't know -- I don't have a Win9x system to test it on.  However, I 
*do* know this: if a user has already installed extensions for the 
current perl, they will NOT carry over to a multiplicity perl.  The pm 
files often go in site_perl/5.6.1/cygwin/  -- but now they are searched 
for in (and new ones will go into) site_perl/5.6.1/cygwin-multi/...

I'm not sure how much of an inconvenience this is.  The perl 
module-installation procedure -- which was in flux "recently" -- 
sometimes modifies files that are part of the main perl dist.

If you install modules, and then re-install perl (even the same cygwin 
perl package) using setup, the files that were modified by module 
installations will get clobbered.  So, given the current "system" -- 
which probably needs some work -- end users may need to reinstall all of 
their custom modules REGARDLESS of whether your new perl is built with 
multiplicity or not.

This is a maintainer judgement call.  I'm willing to defer to you. :-)


> WITH ntsec-harness i got these errors, i wonder why groups.t failed with 
> ntsec in this previous build and failed not without ntsec.
> Also dubious is the pragma/strict error.
> One build before that i got a pragma/warnings error instead of pragma/strict.
> 
> Failed Test      Status Wstat Total Fail  Failed  List of Failed
> ----------------------------------------------------------------------
> lib/glob-basic.t	               9    1  11.11%  8
> op/groups.t     	               2    1  50.00%  1
> pragma/strict.t 	              93    1   1.08%  21
> 8 tests and 94 subtests skipped.
> Failed 3/275 test scripts, 98.91% okay. 3/12830 subtests failed, 99.98% okay.
> 
> After that i patched into groups.t, but it changes nothing.


Strange.  I'm willing to go ahead with this one, if it means having a 
more proactive maintainer who's not MIA.  3 subtest failures 
notwithstanding.  But eventually these should be investigated and squashed.

Have you been able to reproduce any of the binmode/textmode problems 
that folks have reported, or verify that they no longer exist?  (Just 
asking; I don't think it's worth holding up this release on that issue 
alone.  Again, I'd rather move forward -- those bugs if they still exist 
can be corrected in the next one)

--Chuck