Library pragma in PC/config.h
Hi all -- for building extensions with non-MS compilers, it sounds like a small change to PC/config.h is needed. Rene Liebscher suggests changing #ifndef USE_DL_EXPORT /* So nobody needs to specify the .lib in their Makefile any more */ #ifdef _DEBUG #pragma comment(lib,"python20_d.lib") #else #pragma comment(lib,"python20.lib") #endif #endif /* USE_DL_EXPORT */ to #if !defined(USE_DL_EXPORT) && defined(_MSC_VER) ... That way, the convenience pragma will still be there for MSVC users, but it won't break building extensions with Borland C++. (As I understand it, Borland C++ understands the pragma, but then tries to use Python's standard python20.lib, which of course is only for MSVC.) Non-MSVC users will have to explicitly supply the library, but that's OK: the Distutils does it for them. (Even with MSVC, because it's too much bother *not* to specify python20.lib explicitly.) Does this look like the right change to everyone? I can check it in (and on the 1.6 branch too) if it looks OK. While I have your attention, Rene also suggests the convention of "bcpp_python20.lib" for the Borland-format lib file, with other compilers (library formats) supported in future similarly. Works for me -- anyone have any problems with that? Greg -- Greg Ward - programmer-at-big gward@python.net http://starship.python.net/~gward/ Know thyself. If you need help, call the CIA.
Does this look like the right change to everyone? I can check it in (and on the 1.6 branch too) if it looks OK.
I have no problems with this (but am a little confused - see below)
I would prefer python20_bcpp.lib, but that is not an issue. I am a little confused by the intention, tho. Wouldnt it make sense to have Borland builds of the core create a Python20.lib, then we could keep the pragma in too? If people want to use Borland for extensions, can't we ask them to use that same compiler to build the core too? That would seem to make lots of the problems go away? But assuming there are good reasons, I am happy. It wont bother me for some time yet ;-) <just deleted a rant about the fact that anyone on Windows who values their time in more than cents-per-hour would use MSVC, but deleted it ;-> Sometimes-the-best-things-in-life-arent-free ly, Mark.
OK. Better cut my rates. Some people will be pleased ;) Borland C++ isn't that bad. With an optimiser and a decent debugger it'd even be usable as my main compiler. What is good about Borland is that it produces lots of meaningful warnings. I've never regretted ensuring that Scintilla/SciTE build on Windows with each of MSVC, Borland and GCC. It wasn't much work and real problems have been found by the extra checks done by Borland. You-should-try-it-sometime-ly y'rs, Neil
Borland C++ isn't that bad. With an optimiser and a decent debugger it'd even be usable as my main compiler.
You-should-try-it-sometime-ly y'rs,
OK - let me know when it has an optimiser and a decent debugger, and is usable as a main compiler, and I will be happy to ;-) Only-need-one-main-anything ly, Mark.
[Neil Hodgson]
Indeed, the more compilers the better. I've long wished that Guido would leave CNRI, and find some situation in which he could hire people to work on Python full-time. If that ever happens, and he hires me, I'd like to do serious work to free the Windows build config from such total dependence on MSVC.
On 04 August 2000, Mark Hammond said:
I would prefer python20_bcpp.lib, but that is not an issue.
Good suggestion: the contents of the library are more important than the format. Rene, can you make this change and include it in your next patch? Or did you have some hidden, subtle reson for "bcpp_python20" as opposed to "python20_bcpp"?
But that requires people to build all of Python from source, which I'm guessing is a bit more bothersome than building an extension or two from source. Especially since Python is already distributed as a very easy-to-use binary installer for Windows, but most extensions are not. Rest assured that we probably won't be making things *completely* painless for those who do not toe Chairman Bill's party line and insist on using "non-standard" Windows compilers. They'll probably have to get python20_bcpp.lib (or python20_gcc.lib, or python20_lcc.lib) on their own -- whether downloaded or generated, I don't know. But the alternative is to include 3 or 4 python20_xxx.lib files in the standard Windows distribution, which I think is silly.
Then I won't even write my "it's not just about money, it's not even about features, it's about the freedom to use the software you want to use no matter what it says in Chairman Bill's book of wisdom" rant. Windows: the Cultural Revolution of the 90s. ;-) Greg -- Greg Ward - geek-at-large gward@python.net http://starship.python.net/~gward/ What happens if you touch these two wires tog--
Greg Ward wrote:
OK, it is no problem to change it.
(GCC uses libpython20.a) It is not necessary to include the libraries for all compilers. The only thing what is necessary is a def-file for the library. Every compiler I know has a program to create a import library from a def-file. BCC55 can even convert python20.lib in its own format. (The program is called "coff2omf". BCC55 uses the OMF format for its libraries which is different of MSVC's COFF format. (This answers your question, Tim?)) Maybe it should be there a file in the distribution, which explains what to do if someone wants to use another compiler, especially how to build a import library for this compiler or at least some general information what you need to do. ( or should it be included in the 'Ext' documentation. ) kind regards Rene Liebscher
On Tue, Aug 08, 2000 at 01:41:12PM +0200, Rene Liebscher wrote:
Python20 is most important so it should go first. Then I suppose it is debatable whether 'd' or 'bcpp' should come first. My preference is "python20_bcpp_d.lib" because this would maintain the pattern that the basename of debug-built libs, etc. end in "_d". Generally speaking this would give a name spec of python<version>(_<metadata>)*(_d)?.lib Trent -- Trent Mick TrentM@ActiveState.com
On Tue, Aug 08, 2000 at 08:18:12AM -0700, Trent Mick wrote:
On Tue, Aug 08, 2000 at 01:41:12PM +0200, Rene Liebscher wrote:
I forgot to ask which name you would like for debug libraries
"python20_bcpp_d.lib" or "python20_d_bcpp.lib"
may be we should use "bcpp_python20_d.lib", and use the name schema which I suggested first.
Python20 is most important so it should go first.
To clarify something Rene said earlier (I appear to have deleted that mail eventhough I had intended to reply to it :P) 'gcc' names its libraries 'libpython<version>.{so,a}' because that's the UNIX convention: libraries are named 'lib<name>.<libtype>', where libtype is '.a' for static libraries and '.so' for dynamic (ELF, in any case) ones, and you link with -l<name>, without the 'lib' in front of it. The 'lib' is UNIX-imposed, not something gcc or Guido made up. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Tue, Aug 08, 2000 at 08:26:03AM -0700, Trent Mick wrote: [ Discussion about what to call the Borland version of python20.dll: bcpp_python20.dll or python20_bcpp.dll. Rene brought up that gcc calls "its" library libpython.so, and Thomas points out that that isn't Python's decision. ]
Yes, you are right. I was being a Windows bigot there for an email. :)
And rightly so ! :) I think the 'python20_bcpp' name is more Windows-like, and if there is some area in which Python should try to stay as platform specific as possible, it's platform specifics such as libraries :) Would Windows users(*) when seeing 'bcpp_python20.dll' be thinking "this is a bcpp specific library of python20", or would they be thinking "this is a bcpp library for use with python20" ? I'm more inclined to think the second, myself :-) *) And the 'user' in this context is the extention-writer and python-embedder, of course. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
[Greg Ward]
OK by me.
... While I have your attention,
You're pushing your luck, Greg <wink>.
Nope, but I don't understand anything about how Borland differs from the real <0.5 wink> Windows compiler, so don't know squat about the issues or the goals. If it works for Rene, I give up without a whimper.
Does this look like the right change to everyone? I can check it in (and on the 1.6 branch too) if it looks OK.
I have no problems with this (but am a little confused - see below)
I would prefer python20_bcpp.lib, but that is not an issue. I am a little confused by the intention, tho. Wouldnt it make sense to have Borland builds of the core create a Python20.lib, then we could keep the pragma in too? If people want to use Borland for extensions, can't we ask them to use that same compiler to build the core too? That would seem to make lots of the problems go away? But assuming there are good reasons, I am happy. It wont bother me for some time yet ;-) <just deleted a rant about the fact that anyone on Windows who values their time in more than cents-per-hour would use MSVC, but deleted it ;-> Sometimes-the-best-things-in-life-arent-free ly, Mark.
OK. Better cut my rates. Some people will be pleased ;) Borland C++ isn't that bad. With an optimiser and a decent debugger it'd even be usable as my main compiler. What is good about Borland is that it produces lots of meaningful warnings. I've never regretted ensuring that Scintilla/SciTE build on Windows with each of MSVC, Borland and GCC. It wasn't much work and real problems have been found by the extra checks done by Borland. You-should-try-it-sometime-ly y'rs, Neil
Borland C++ isn't that bad. With an optimiser and a decent debugger it'd even be usable as my main compiler.
You-should-try-it-sometime-ly y'rs,
OK - let me know when it has an optimiser and a decent debugger, and is usable as a main compiler, and I will be happy to ;-) Only-need-one-main-anything ly, Mark.
[Neil Hodgson]
Indeed, the more compilers the better. I've long wished that Guido would leave CNRI, and find some situation in which he could hire people to work on Python full-time. If that ever happens, and he hires me, I'd like to do serious work to free the Windows build config from such total dependence on MSVC.
On 04 August 2000, Mark Hammond said:
I would prefer python20_bcpp.lib, but that is not an issue.
Good suggestion: the contents of the library are more important than the format. Rene, can you make this change and include it in your next patch? Or did you have some hidden, subtle reson for "bcpp_python20" as opposed to "python20_bcpp"?
But that requires people to build all of Python from source, which I'm guessing is a bit more bothersome than building an extension or two from source. Especially since Python is already distributed as a very easy-to-use binary installer for Windows, but most extensions are not. Rest assured that we probably won't be making things *completely* painless for those who do not toe Chairman Bill's party line and insist on using "non-standard" Windows compilers. They'll probably have to get python20_bcpp.lib (or python20_gcc.lib, or python20_lcc.lib) on their own -- whether downloaded or generated, I don't know. But the alternative is to include 3 or 4 python20_xxx.lib files in the standard Windows distribution, which I think is silly.
Then I won't even write my "it's not just about money, it's not even about features, it's about the freedom to use the software you want to use no matter what it says in Chairman Bill's book of wisdom" rant. Windows: the Cultural Revolution of the 90s. ;-) Greg -- Greg Ward - geek-at-large gward@python.net http://starship.python.net/~gward/ What happens if you touch these two wires tog--
Greg Ward wrote:
OK, it is no problem to change it.
(GCC uses libpython20.a) It is not necessary to include the libraries for all compilers. The only thing what is necessary is a def-file for the library. Every compiler I know has a program to create a import library from a def-file. BCC55 can even convert python20.lib in its own format. (The program is called "coff2omf". BCC55 uses the OMF format for its libraries which is different of MSVC's COFF format. (This answers your question, Tim?)) Maybe it should be there a file in the distribution, which explains what to do if someone wants to use another compiler, especially how to build a import library for this compiler or at least some general information what you need to do. ( or should it be included in the 'Ext' documentation. ) kind regards Rene Liebscher
On Tue, Aug 08, 2000 at 01:41:12PM +0200, Rene Liebscher wrote:
Python20 is most important so it should go first. Then I suppose it is debatable whether 'd' or 'bcpp' should come first. My preference is "python20_bcpp_d.lib" because this would maintain the pattern that the basename of debug-built libs, etc. end in "_d". Generally speaking this would give a name spec of python<version>(_<metadata>)*(_d)?.lib Trent -- Trent Mick TrentM@ActiveState.com
On Tue, Aug 08, 2000 at 08:18:12AM -0700, Trent Mick wrote:
On Tue, Aug 08, 2000 at 01:41:12PM +0200, Rene Liebscher wrote:
I forgot to ask which name you would like for debug libraries
"python20_bcpp_d.lib" or "python20_d_bcpp.lib"
may be we should use "bcpp_python20_d.lib", and use the name schema which I suggested first.
Python20 is most important so it should go first.
To clarify something Rene said earlier (I appear to have deleted that mail eventhough I had intended to reply to it :P) 'gcc' names its libraries 'libpython<version>.{so,a}' because that's the UNIX convention: libraries are named 'lib<name>.<libtype>', where libtype is '.a' for static libraries and '.so' for dynamic (ELF, in any case) ones, and you link with -l<name>, without the 'lib' in front of it. The 'lib' is UNIX-imposed, not something gcc or Guido made up. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Tue, Aug 08, 2000 at 08:26:03AM -0700, Trent Mick wrote: [ Discussion about what to call the Borland version of python20.dll: bcpp_python20.dll or python20_bcpp.dll. Rene brought up that gcc calls "its" library libpython.so, and Thomas points out that that isn't Python's decision. ]
Yes, you are right. I was being a Windows bigot there for an email. :)
And rightly so ! :) I think the 'python20_bcpp' name is more Windows-like, and if there is some area in which Python should try to stay as platform specific as possible, it's platform specifics such as libraries :) Would Windows users(*) when seeing 'bcpp_python20.dll' be thinking "this is a bcpp specific library of python20", or would they be thinking "this is a bcpp library for use with python20" ? I'm more inclined to think the second, myself :-) *) And the 'user' in this context is the extention-writer and python-embedder, of course. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
[Greg Ward]
OK by me.
... While I have your attention,
You're pushing your luck, Greg <wink>.
Nope, but I don't understand anything about how Borland differs from the real <0.5 wink> Windows compiler, so don't know squat about the issues or the goals. If it works for Rene, I give up without a whimper.
participants (7)
-
Greg Ward -
Mark Hammond -
Neil Hodgson -
Rene Liebscher -
Thomas Wouters -
Tim Peters -
Trent Mick