|
in reply to Re^2: [JOB] The Perl Foundation seeks Windows Developer
in thread [JOB] The Perl Foundation seeks Windows Developer
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.
|
Re^4: [JOB] The Perl Foundation seeks Windows Developer
by demerphq (Chancellor) on Apr 02, 2006 at 20:13 UTC
|
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] |
Re^4: [JOB] The Perl Foundation seeks Windows Developer
by rhesa (Vicar) on Apr 02, 2006 at 19:51 UTC
|
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] |
Re^4: [JOB] The Perl Foundation seeks Windows Developer
by adamk (Chaplain) on Apr 03, 2006 at 04:28 UTC
|
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] |
Re^4: [JOB] The Perl Foundation seeks Windows Developer
by syphilis (Archbishop) on Apr 03, 2006 at 02:11 UTC
|
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] |
Re^4: [JOB] The Perl Foundation seeks Windows Developer
by adamk (Chaplain) on Apr 03, 2006 at 05:35 UTC
|
This is not about DLLs. The problems with compiler compatibility has been largely fixed.
95% of the problems are in non-C areas.
| [reply] |
|
|
