This is the mail archive of the cygwin 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: understanding effects of moving addons from site_perl to vendor_perl

Hello linda,

Am Montag, 30. August 2004 um 02:14 schriebst du:

>> 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?

Well, you may keep the previous until libwin32 is updated.

> 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.

There is one problem with changed gcc behaviour, a switch is needed
--enable-stdcall-fixup probably, then there is another unresolved
problem with the OLE module.

> 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'm thinking about changing the naming scheme, to reflect this.

> 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)...

Windows comes with perl (well as an addon in the resource kit) since
nearly 10 years.


Unsubscribe info:
Problem reports:

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