|
in reply to Re: [JOB] The Perl Foundation seeks Windows Developer
in thread [JOB] The Perl Foundation seeks Windows Developer
adamk wrote:
The aim is to provide CPAN authors a Win32 Perl platform that is similar in use and style to the Unix Perls, to make it easier for them to port to Win32, and to provide a suitable basic Perl platform for experienced Perl developers that prefer to install from CPAN, instead of using binary packages.
I didn't read that as aiming for a replacement of ActivePerl. Having a sensible toolchain on Win32 would remove much of the perceived reluctance to develop on that platform, because it would be much easier to start working _right away_, without having to dig around for compilers, header files, and what not.
I'm also guessing this would benefit the AS distribution in the long run, since it would mean more modules will build on Win32, which means AS will be able to package those too.
You wrote:
I imagine that any *nix programmer that encountered this problem when trying to port their module to Win32 would probably take one look, blame it on a broken MS C compiler/CRT and understandably give up, but the problem lies within the the perl sources.
That might very well be true right now. If this project succeeds, that argument would no longer be true, since we'd be using the same tool chain on both platforms. The grant also asks for fixing bugs like these.
You wrote:
Maybe Strawberry is only the starting point and would enable/encourage more people to become actively involved in making Perl work better on Win32?
I believe that's the goal, yes, absolutely.
Even though I said goodbye to Win32 long ago (a personal and professional luxury, I know), I do see this as a valuable plan: it would improve perl for a very large user base, integrating their development practices with those of unixy platforms; making more modules available to them means an expanded user base, which means more eyeballs, which implies improved code. I feel that's a win-win situation for both camps. Having used that word, I even have hope we won't be speaking of "both camps" in the future. |
Re^3: [JOB] The Perl Foundation seeks Windows Developer
by BrowserUk (Patriarch) on Apr 02, 2006 at 19:22 UTC
|
I'm also guessing this would benefit the AS distribution in the long run, since it would mean more modules will build on Win32, which means AS will be able to package those too.
Um. The problem is, will it?
Are the DLLs produced by compiling XS code with MinGW compatible with a Perl built with MS VC++? If not, how will allowing module authors to "get away" with making minimal changes to their modules in order to achieve successful tests under Vanilla/Strawberry enable those same packages to pass the AS autobuild process?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
Are the DLLs produced by compiling XS code with MinGW compatible with a Perl built with MS VC++?
Assuming that the VC++ is VC6 then yes, if its VC7 then yes, but not if you use C++, if its VC8 then no.
The rule is that it doesnt matter what compiler was used, it matters what CRT is in use. Since stuff built with both VC6 and MINGW link against MSVCRT60.dll they are able to coexist peacefully. Similarly MSVCRT60 and MSVCRT70 are compatible in terms of C linking, but C++ exceptions will cause a problem. Luckily the use of C++ is rare in Perl.
Also as of later AS Perl builds you can compile using either MINGW or VC. If VC isnt available and MINGW is then EUMM will automatically use the latter.
---
$world=~s/war/peace/g
| [reply] |
|
|
Aren't you implying that the AS distribution is the reference to which all Perl module authors should conform? Why wouldn't it be the other way around?
I don't see why AS couldn't switch to gcc for their builds (theoretically speaking). At the very least, Strawberry will give _them_ something to build and test against.
In any case, Strawberry would give module authors a tool to test these things for themselves. The barriers to that are currently too high, in my opinion. Whether they will make use of that option is another question, but it seems obvious that they won't _without_ these tools.
| [reply] |
|
|
Aren't you implying that the AS distribution is the reference to which all Perl module authors should conform?
No. I'm saying that for the Win32 Perl user, AS is the defacto standard that makes Perl usable on Win32. It maybe that non-win32 Perl users see POSIX as the ultimate expression of cross systems compatibility, but it just misses the mark in so many ways for win32 users and programmers, that moving 2 steps closer to POSIX compatibilty and 15 steps further away from being able to utilise the features of our OS is no progress at all.
Presumably, the purpose of the exercise is to make Perl more usable on Win32? If so, I do not think that you achieve that by throwing away much of what AS perl already provides in order to gain what? I can already build most of CPAN on Win32 with existing tools and most of what I cannot build will not be fixed by throwing away half of what I already have.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
Yes, it will absolutely benefit AS in the long fun, and in fact in the short run too.
Because Vanilla has allowed the feedback loop to be shortened, we've been able to fix more than a dozen bugs in various areas that afflict ActivePerl as well, in places like CPAN.pm, Term::ReadLine, Win32API::Registry and others.
There are not bugs in C code related, they are bugs in Perl code. In fact, in some cases, I cannot see how the module could possibly build AT ALL so that it could be bundled into AP.
The VAST majority of bugs encountered so far have nothing to do with compilers at all. They are ordinary bugs in ordinary code. But perhaps because they are bundled, or perhaps because the feedback loop is at 6 month intervals, they aren't getting fixed.
| [reply] |
|
|
Are the DLLs produced by compiling XS code with MinGW compatible with a Perl built with MS VC++?
Yes they are - and vice versa, too. I've often mixed things in this way (in both directions). Exceptions may exist - such as Inline::C and Inline::CPP, where you've built an extension that expects you to be using gcc (or cl) and run it with a perl that expects you to be using cl (or gcc). If the VC++ compiler in question is other than version 6.0 then you might strike an additional (very rare) problem because of different runtimes being used.
(I also wondered what Strawberry will achieve. Having read this thread, I can't see that it has anything to offer me ... but that's about all I've been able to deduce ...)
Cheers,
Rob
| [reply] |
|
|
This is not about DLLs. The problems with compiler compatibility has been largely fixed.
95% of the problems are in non-C areas.
| [reply] |
|
|
