Dropping the overzealous enforcement of an arbitrary division doesn't constitute "a bug".
Enabling code to work, with the caveat that it may fail at some point in the future if it becomes necessary to modify the APIs it utilises, for CORE reasons, is simply pragmatic.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Dropping the overzealous enforcement of an arbitrary division doesn't constitute "a bug"
Aaah ... yes, I guess you could solve the problem by convincing the porters that they are being overzealous. My feeling is that you probably won't get too far - though I'm basing that solely on the responses I received from Jan Dubois about this issue in this thread to the perl-win32-users mailing list.
Of course, Jan Dubois != p5p. (I think that p5p is the place to raise this if you want to get somewhere with it.)
Maybe they could make it so that *every* symbol is available if, in our xs code, we:
#define IT_IS_THE FAULT_OF_THE_AUTHOR_WHEN_IT_BREAKS
Cheers,
Rob | [reply]
[d/l] |
Aaah ... yes, I guess you could solve the problem by convincing the porters that they are being overzealous.
Another way of interpreting what I wrote is that the compiler/linker/build process is being overzealous on Win32.
Having read the mailing list thread, it strikes me that the whole #define PERL_CORE / #define PERL_EXT / marking of APIs as EX and not A, is exactly what I'm suggesting.
Export the functions without making them a part of the official API. The only argument is whether it is done piecemeal for those non-api entrypoints used by non-conformant but 'accepted as useful' modules. Or pragmatically, to match the situation that exists on the reference platform.
Note though that I am not trying to persuade anyone such a change should be made. Only pointing out that life for Win32 users and developers, as well as non-Win32 developers who's code breaks when ported to win32, would be much simpler were that change made.
For now, I'm simply trying to build all the modules that I've grown dependant upon with 5.8.x into my 5.10 build so that I can move over to using the later as my default. And I am finding it far simpler to manually build the modules using a single compiler command line, than to either get PPMs for 5.10 that work, or resolve the problems with the generated makefiles.
The other day I spent just 15 minutes to work out the command line required to build Win32::Daemon manually. I had already spent nearly 5 hours trying to work out how to adapt the generated makefile--and failed. And I've previously spent literally weeks trying to work out, or get advice here and elsewhere, on how to get EU::MM to produce the makefile that I've worked out is required to build a package.
It's just a case of following the path of least resistance. Both with the tools and the powers that be.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |