Subject: Re: cygwin/Perl and Win32:: package(s)
From: "Gerrit P. Haase" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 24 May 2002 17:39:28 +0200

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/