From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16617 invoked by alias); 7 Apr 2014 21:31:51 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 16602 invoked by uid 89); 7 Apr 2014 21:31:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f173.google.com Received: from mail-vc0-f173.google.com (HELO mail-vc0-f173.google.com) (209.85.220.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 07 Apr 2014 21:31:48 +0000 Received: by mail-vc0-f173.google.com with SMTP id il7so30598vcb.18 for ; Mon, 07 Apr 2014 14:31:45 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.122.164 with SMTP id lt4mr22658026veb.2.1396906305638; Mon, 07 Apr 2014 14:31:45 -0700 (PDT) Received: by 10.220.159.197 with HTTP; Mon, 7 Apr 2014 14:31:45 -0700 (PDT) In-Reply-To: <8761mlx7im.fsf@Rainer.invalid> References: <534078A2.4000601@tiscali.co.uk> <87bnwf2cjl.fsf@Rainer.invalid> <534174C4.5010608@tiscali.co.uk> <87y4zi1kib.fsf@Rainer.invalid> <5341A3F5.2040506@tiscali.co.uk> <8761mlx7im.fsf@Rainer.invalid> Date: Mon, 07 Apr 2014 21:31:00 -0000 Message-ID: Subject: Re: 64-bit: Missing perl modules From: Reini Urban To: cygwin-apps Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00022.txt.bz2 On Mon, Apr 7, 2014 at 2:29 PM, Achim Gratz wrote: > Reini Urban writes: >> The new 5.18.2 package will be unified for 32bit and 64bit, yes. > > Looking forward to it... > >> perl_vendor will probably stay as is, as it is the easiest for the >> user and the maintainer. > > I beg to differ. It would be vastly easier for everyone if perl_vendor > simply depended on those packages that are now hidden inside it. Let me > know what's inside the new perl_vendor and I'll help to produce those > single distribution packages. Nope. >> I still need to rebase all most-used XS modules esp. on 32bit perl to >> make sense and avoid dll base collisions on forks, which happens with >> CPAN, a basic bootstrap problem. > > I've not been doing that for more than two years now and have actually > backed out the respective changes in MakeMaker, IIRC. As long as I'm > using cygport I'm not running into problems (except for PDL since this > produces several DLL that initially occupy the same address space, which > is easily taken care of with an ephemeral rebase before testing). You can do individual perlrebase or wait for the full autorebase for every XS installation. With individual split perl_vendor packages the user needs to wait for every single rebase update. With the combined perl_vendor I'll do it as part of the build step and the user only needs to wait for one rebase run. >> My cygwin-specific rebase framework for CPAN modules still needs some >> love, esp. on 32bit. > > I'm doing incremental auto-rebase on install, YMMV. Sure, that's automatic of you care to package everything. But updates come every week, not every two years. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/