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 From: perlspinr AT att DOT net To: cygwin AT cygwin DOT com Cc: Clive Nicolson Subject: Re: cygwin/Perl and Win32:: package(s) Date: Thu, 23 May 2002 22:09:07 +0000 Message-Id: <20020523220908.ENVC5116.mtiwmhc23.worldnet.att.net@webmail.worldnet.att.net> "Gerrit P. Haase" wrote: > Am Donnerstag, 23. Mai 2002 um 19:02 schriebst Clive Nicolson : > > >> Yes, that would be a great contribution. I think it should live at CPAN > >> as a separate category similar to the Win32:: hierarchy named Cygwin:: > > I think it should remain named Win32::, it will be largely functionally > > identical, having two differently named packages will lead to all sorts of > > problems! I'll have a go at getting the libwin32 maintainer to accept my > > changes when I'm done, otherwise it will have to be a separate package. > > Hmm, I don't think it is a good idea. Cygwin Perl is completely > different from the Win32 version. It is another OS! And all the OS's > have their own Perl version with all the specials, VMS Perl, MacPerl, > Win32, why not Cygwin too? I would tend to agree mostly with Clive, except for: > E.g. we will have /dev/registry soon and we can use the Cygwin API to > access the registry. Well, yes, if there is a "native" Cygwin API way to access the Registry, then that defnitely weighs in on the side of keeping the module functionality under separate names. However that still doesn't address the other Win32:: module functionality that Clive has got working. He's mentioned Win32::ODBC specifically, but in fact, I am thinking, underneath many of the specialized Win32:: modules there are dependencies on more basic Win32:: modules, and what he's accomplished is to get all *those* modules working under Cygwin, too. If I understood correctly. Clive, I'd like to suggest or request you do something for me as a personal favor: would you please post a follow-up msg in which you list the modules that Win32::Registry and Win32::ODBC depend on? That's a bit of work, but you've been working so hard, you'll hardly notice a little more, right ;-)? (BTW I think there's an existing Perl program or module to help in the chore of listing module dependencies -- check search.cpan.org or perlmonks.org). > It would be more effective to use all the Posix features we have thanks > to Cygwin and kick out all the workarounds in the Win32 parts. Just take > the main parts. > > Also it will be a lot of work to convince the libwin32 maintainers to > include all the special stuff for Cygwin. I would like to have it > separated from the Win32 hierarchy. I "hear" you, Gerrit, but I don't think I agree with the basic thrust. I'll try to explain why although I suspect you'll be a little resistant. There's a bit of "Cygwin Territoriality" for me in my reading of your reasoning. I think a strong case can be made that this *conflicts philosophically* with the Perl Way, which is different. Your approach seems isolationist and Perl tends to be cross-cultural, even promiscuous. Perl tends to want to BE the platform, as much as possible -- that is, to assimilate as many sub-idioms as it needs to in order to pragmatically get the work done. Perl wants to obliterate or minimize the distinctions between 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. I can see something like that happening with Win32::. 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" regarding a pan-platform set of functionalities, we might instead change the granularity, so to speak, and say "now we apply that principle at the level where it has relevence, that is, to the Win32- specialized categories of things to teach Perl about". The Registry being a prime example. So one result of this thinking is possibly that there should *not* be new Cygwin:: modules incorporating what Clive has worked on and/or others may develop, but instead should be new Win32::FOOBAR::Cygwin sub- tree'd modules that can be integrated into future releases of their parent modules by analogy to how the File::Spec "hidden" modules integrate into File/Spec.pm itself. 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. 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. 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. > >> I would like to test it with bleadperl because perl- 5.6 is stable and > >> hopefully soon we'll have a new perl, perl-5.8;) > > > I have managed to get Win32:: and Win32::Registry going under cygwin, and > > have had a go at Win32::ODBC. > > There is also an ODBC module which works besides the Win32 hierarchy. > I don't know if it works with recent versions too, haven't tried, but it > worked with some previous verion, see here: > http://testers.cpan.org/search?request=dist&dist=DBD- ODBC&macid=130 > > > For Win32::, I took per-5.6.1/win32/win32.[ch] and split them into 2, > > Win32.[ch] and Win32core.[ch] . Win32core.[ch] contains the code to > > implement Win32:: functionality. I copied Win32core. [ch] to the top level > > dir of libwin32 and built the Makefile. After much fiddling I managed to > > get Win32core compiled and linked with the original libwin32 "boot" code. > > > I installed the resulting dll in the appropriate perl dir and moved on to > > Win32::Registry . I hacked this till it compiled and linked. I installed > > this and invoked the test script which reported no errors. > > > I added Win32::Registry code to my original perl script and have managed > > to extract values from the Registry. > > E.g. we will have /dev/registry soon and we can use the Cygwin API to > access the registry. > > > To get this hack to build "out of the box" requires some fiddles using > > Makemaker which I have yet to sort out. I'll ask some questions about > > this (like how do I set LDLOADLIBS in the Makefile) after I've got some > > sleep! > > The Makemaker stuff is improved since perl-5.6.1 very much! That's good news ;-). Makemaker had become a nightmare I shudder to think about revisiting. Best Regards, Soren Andersen (perlpsinr) -- 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/