Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Fri, 24 May 2002 17:39:28 +0200 From: "Gerrit P. Haase" Reply-To: "Gerrit P. Haase" Organization: Esse keine toten Tiere X-Priority: 3 (Normal) Message-ID: <121226670769.20020524173928@familiehaase.de> To: perlspinr AT att DOT net CC: cygwin AT cygwin DOT com Subject: Re: cygwin/Perl and Win32:: package(s) In-Reply-To: <20020523220908.ENVC5116.mtiwmhc23.worldnet.att.net@webmail.worldnet.att.net> References: <20020523220908 DOT ENVC5116 DOT mtiwmhc23 DOT worldnet DOT att DOT net AT webmail DOT worldnet DOT att DOT net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Soren schrieb: > platforms. One example of what I mean might be the > File::Spec heirarchy of > modules. You do not call "File::Spec::Mac" on a Mac > and "File::Spec::OS2" on > OS2. Rather, you just {use File::Spec} and Perl > integrates the appropriate > sub-module automagically. The base of that system is > File::Spec::Unix but > then what is in there that's foundational gets > moderated / modulated by > whatever platform idiom is necessary. That is the point, e.g. Cygwin uses File::Spec::Unix and not File::Spec::Win32 and there are a lot of parts under Win32 which will use special Win32 modules or submodules which are not needed in Cygwin Perl. We go the other direction. We don't make Cygwin Perl to get closer to Win32 but we make Cygwin to get closer to Unix. > There's no real > widely-agreed-on parallel to the Win32 Registry, for > example, outside of MS > Windows. So instead of saying "this is how Perl is done" Cygwin Perl is linked against cygwin1.dll and if you want to access the Registry we don't need a Module to do it, we use cygwin1.dll to do it and access the registry values like files on the disc. Since we need to load cygwin1.dll we can do this at the same time. And so is it with many other parts in the Win32 hierarchy, there are lots of workarounds for things that are not needed in the Cygwin world because Cygwin already includes these workarounds. > The whole philosophy of Perl modules is or originally > was to most effectively enable the writing of > *portable*, idiomatic Perl code in applications. I feel > that making the choice that "Cygwin is so psychotic (un- > *NIX-like) that it has to have it's own Kind of Perl, > like MacPerl and VMSPerl", would be a big retreat. > Splintering, fragmenting. Well, as you stated there is nothing but Win32 which has a Registry and there is nothing but Cygwin which has a /dev/registry so why should I use my time to reimplement what Chris J. already has done? So using this /dev/registry will never be platform independent and so it is with many other parts. > There may be lots of examples of platform-specific > modules on CPAN but there > is also a lot of *crap* on CPAN that hardly anyone ever > uses. I do not think > Cygwin should encourage top-level module heirarchy > proliferation needlessly. > Instead I think a more courageous road is to determine > to work on discussions with other > groups of Perl developers to make existing pieces of > widely-used and core Perl > "smart" about Cygwin. I hope I got this right. At this point perl-5.7.3 (bleadperl) builds without problems, OOTB. There was a lot of tweaking and now it is easy to build a Cygwin Perl. If you think that Cygwin relevant code should go into the Win32 subtree (which is in the perl core included) then you need to go to the perl5-porters and discuss it with them. If you get the Win32 'core' included in Cygwin Perl all the Win32 modules will build OOTB. Someone needs to do the work. This is done now (well initial work was done), lets see how to get this into Cygwin Perl. > In this vein, we introduce a > revolutionary new mindset > in which we take the old "Perl is basically about *NIX -- > *NIX is THE > platform and we treat other OS's as sub-variants > (however psychotic) of > *NIX" thing, and now re-invent it a little, saying "now, > for the purposes of > advancing Perl use on Windows, we take a 'Win32-Perl is > the platform and > msvcrt-based coding is a sub-variant of that, and so is > cygwin1.dll > a sub-variant of that' approach". > That's my 6 cents on the matter. I think bouncing these > ideas off someone > who's talked a lot with Larry might be a good idea > before any firm decision > is made. Yes, we should discuss this at the perl5-porters list. Gerrit -- =^..^= -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/