On 9 Aug 2002, Martin v. [iso-8859-15] L=F6wis wrote:
> If you are familiar with the code, it would be good if you could
> comment on the following questions:
>
> - should os2module.c get its own source code file as well?
>
> - are the #ifdefs in the resulting ntmodule.c still needed?
> I believe they are, as the various compilers appear to support
> different sets of functions in their C libraries. Of course,
> most of these could be eliminated if the C is avoided in favour
> of the Win32 API. Alternatively, can anybody with access to any
> of these compilers (BorlandC, Watcom, IBM) please comment on
> which functions provided by MSVC are missing in those compilers?
I don't have a problem with the OS/2 stuff being split out as well.
However I think there is some merit to Tim's point (added as a comment to
the patch) about trying to contain the natural divergence of API support
if the code is completely split out.
I haven't looked at the your patch (just the SF patch manager
entry, sorry), but if a split is pursued, I would would find an approach
similar to the thread_* and dynload_* bits (in Python/) somewhat more in
keeping with the above reservation.
This approach would have a master module file (eg platformmodule.c) which
contains the init function and the PyMethodDef array (with methods
controlled by HAVE_method #ifdefs as appropriate), and includes
the platform specific implementation files.
I have had thoughts about doing this before, but the scale of the task and
the fact that I don't have a Windows dev box for testing put me off.
--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au | Snail: PO Box 370
andymac@pcug.org.au | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4