Mail Archives: cygwin/2002/05/23/18:09:43
"Gerrit P. Haase" <gp AT familiehaase DOT de> wrote:
> Am Donnerstag, 23. Mai 2002 um 19:02 schriebst Clive
Nicolson <clive AT baby DOT bedroom DOT gen DOT 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/
- Raw text -