On Sun, Apr 6, 2014 at 1:59 PM, David Stacey wrote: > On 06/04/14 17:38, Achim Gratz wrote: >> >> David Stacey writes: >>> >>> Thank you for your reply. Yes, I was aware of that discussion. I'm not >>> talking about breaking up 'perl_vendor' for 32-bit Cygwin (although >>> IMHO that would be a good thing in the long term). I'd just like to >>> see the perl modules I mentioned adding to 64-bit Cygwin - and I'm >>> happy to maintain those packages myself if no-one else want to claim >>> ownership. >> >> I don't see why it should be a good idea to have different packaging for >> the two architectures, so I still think this issue needs to be decided. > > > Agreed. Hopefully the different collections of perl modules that are > available in the two architectures can be unified with the next perl > release. > > >> Anyway, here's what I have: > > > Yes, those are more or less identical to the packages that I prepared - I > could have done with those links a few days ago :-) It's rather nice (albeit > inefficient) to have two people trying to do the same thing - so often in > open source programmes no-one has the time! You've obviously put some > thought and effort into this, so I'm happy to step back and let you (or > Reini) to maintain these perl modules. The important thing is that they end > up in 64-bit Cygwin at some point. > > Thankfully, cygport makes most perl modules absurdly easy to maintain. So if > you need someone to adopt a few if and when 'perl_vendor' gets split up then > please let me know. > > Dave.
The new 5.18.2 package will be unified for 32bit and 64bit, yes. perl_vendor will probably stay as is, as it is the easiest for the user and the maintainer. 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. My cygwin-specific rebase framework for CPAN modules still needs some love, esp. on 32bit. -- Reini Urban http://cpanel.net/ http://www.perl-compiler.org/
