[Patches] [ python-Patches-566100 ] Rationalize DL_IMPORT and DL_EXPORT
noreply@sourceforge.net
noreply@sourceforge.net
Fri, 05 Jul 2002 11:45:05 -0700
Patches item #566100, was opened at 2002-06-08 01:14
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=566100&group_id=5470
Category: Core (C code)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Rationalize DL_IMPORT and DL_EXPORT
Initial Comment:
Tim and I agreed that DL_IMPORT/DL_EXPORT is both sucky
and broken. We have come up with purpose oriented
macros to replace them.
PyAPI_FUNC: public Python functions
PyAPI_DATA: public Python data
PyMODINIT_FUNC: extension module init functions.
These cover all existing cases of DL_IMPORT and
DL_EXPORT in the core.
This patch simply introduces the new macros (keeping
the old ones), and changes a small amount of code to
actually use these macros. The vast majority of the
existing Python code using DL_IMPORT/DL_EXPORT has not
been touched.
I have a patch that changes the following:
* PC/pyconfig.h - creates the new PyAPI/MODINIT macros,
but also rationalizes this header file considerably.
All common macros between the various compilers have
been moved to a common section. This simplifies the
header significantly.
* Include/pyport.h - creates the new PyAPI/MODINIT
macros for non windows platforms.
* Include/import.h - move to the new macros. I picked
this header file at random, mainly to prove that the
new macros do indeed work.
* PC/_winreg.c, Modules/_sre.c, Modules/pyexpat.c -
move to the PyMODINIT_FUNC macro.
Patch tested on Windows and Linux.
----------------------------------------------------------------------
>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-05 14:45
Message:
Logged In: YES
user_id=33168
I think Martin checked in the change to drop support for win16,
so some of the macros may have changed (MS_WINDOWS, MS_WIN32).
Won't all the files which use DL_*PORT (most headers in
Include) will have to change?
Michael's explanation of autoconf is what I do. Make sure
you have version 2.53 though.
Let me know if you want me to test on linux.
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2002-07-05 02:45
Message:
Logged In: YES
user_id=14198
ok - thanks! Attaching a new patch that works correctly
with autheader. I'm gunna need help checking this in tho,
but one step at a time <0.1 wink>
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-07-04 08:28
Message:
Logged In: YES
user_id=6656
pyconfig.h.in is a bit like configure. when you edit
configure.in, you're expected to run autoconf to make the
configure script and check that in too. same with
pyconfig.h.in, except that it is made by autoheader.
try running autoheader and see what happens.
(I hope someone -- Martin? -- will correct me if I have this
wrong).
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2002-07-03 21:35
Message:
Logged In: YES
user_id=14198
I'm a little confused by pyconfig.h.in. Can someone please
explain the process to me? What I see is:
* reverting my pyconfig.h.in change prevents the new symbol
from appearing in pyconfig.h
* A CVS log of pyconfig.h.in shows heavy editing, with at
least 6 well-commented checkins in June alone.
So, all the evidence points that pyconfig.h.in does need
modification. Can someone please clarify?
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-07-02 06:16
Message:
Logged In: YES
user_id=6656
Um, you are aware that pyconfig.h.in is auto-generated (by
autoheader)?
But if you've made edits to configure.in, you're probably ok.
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2002-07-01 21:47
Message:
Logged In: YES
user_id=14198
OK - here is a new ambitious patch ;) It attempts to
rationalize all platforms, not just the PC.
* pyport.h now sets up most of the import/export magic. It
looks for Py_ENABLE_SHARED and Py_BUILD_CORE (both new
macros) that control the behaviour.
* Py_ENABLE_SHARED has been added to pyconfig.h.in and
configure.in, so that this macro is created in pyconfig.h
whenever '--enable-shared' is passed to configure.
Py_BUILD_CORE is passed via a "/D" option only when the core
itself is built (ie, not extensions etc)
* PC/pyconfig.h has been rationalized heavily.
* A couple of places in the core have been changed to use
the new macros - more to test that it actually works.
This has been tested on Windows using MSVC, Windows using
cygwin/gcc, and RH7 linux. I consider it basically "done"
so please comment away.
----------------------------------------------------------------------
Comment By: Fredrik Lundh (effbot)
Date: 2002-07-01 14:03
Message:
Logged In: YES
user_id=38376
+1 (possibly except for the MODINIT_FUNC name...)
and yes, _sre.c is supposed to compile under earlier versions
as well, but I can fix that later on.
</F>
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2002-06-23 23:18
Message:
Logged In: YES
user_id=33168
I like the idea, but haven't looked at the patch.
I hope to look soon and give better feedback.
But I'll wait until after you upload the new version. :-)
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2002-06-21 01:20
Message:
Logged In: YES
user_id=14198
Just incase anyone was going to have a look at this <wink>,
I am working on a better version by integrating some of the
cygwin autoconf work. Just want to avoid wasting other's time
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=566100&group_id=5470