This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin/Perl and Win32:: package(s)


"Gerrit P. Haase" <gp@familiehaase.de> wrote:

> Am Donnerstag, 23. Mai 2002 um 19:02 schriebst Clive 
Nicolson <clive@baby.bedroom.gen.nz>:
> 
> >> 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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]