understanding effects of moving addons from site_perl to vendor_perl

[linda w]

>I think I can include libwin32 with the main perl package, but there
>are problems building it, there is a bug in some w32api headers and
>one part is not building at all (OLE).
>  
>
That would be cool if there was 1 package -- would more guarantee them 
being in sync.  I tend to agree...I guess I was lucky before this -- 
either I got the libwin32 with the perl-dist, or libwin32 has been kept 
in sync with perl.  Maybe
the next release of perl was kept in the "Experimental"  state until the lib
was sync'ed?

Why would there be a bug in building it?  Has the win32 interface changed
since the last perl release or did the cygwin headers somehow get mangled?
Strange.

I wasn't aware that all modules have to be re-installed with
each bug-fix release as Reini suggests. I would have guessed that
it should only be necessary (and maybe not even then) between
major (5.4->5.6, 5.6->5.8, etc.) releases.  Oh well.

I think it'd be great if the win32-lib library became part of the perl-win32
release.  It seems that which perl is often used for (system admin scripts
and such) would be more difficult or not possible without the win32 
interface.
It would also make for a more stable win32 development platform, I think.

Occasionally, I send emails to the "scripting guys" at Microsoft asking 
to show
some of their scripting talents in something other than Visual Basic or some
proprietary MS language.  Would be sorta neat if they demo'ed using standard
scripting languages such as bash, perl or python to do system management/
maintenance tasks.  I refer them to the cygwin platform as being a good 
place
to experiment with such languages and I've heard that perl is used 
internally
by programmers (not sure for what, though)...

-linda


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/