[Distutils] libraries options

[Robin Becker]

In article <3A7EF75F.BE1B5E56@lemburg.com>, M.-A. Lemburg
<mal@lemburg.com> writes
>Robin Becker wrote:
.....
>> OK I have been using static libs with distutils for a couple of days and
>> have noticed the following.
>> 
>> 1) Under win32 at least the .lib files are placed by default in
>> temp.win32-2.0\ imho they should be placed alongside other object
>> modules.
>> 
>> 2) The lib objects aren't placed in a release/debug subdirectory.
>> 
>> 3) If a dynamic lib of the same name is present in one of the
>> directories mentioned in a libpath option that lib gets used first
>> (wrongly).
>
>Hmm, the source says:
>
>            # The MSVC linker generates .lib and .exp files, which cannot be
>            # suppressed by any linker switches. The .lib files may even be
>            # needed! Make sure they are generated in the temporary build
>            # directory. Since they have different names for debug and release
>            # builds, they can go into the same directory.
>
and for _ext builds they do indeed make these in the appropriate place

eg building bingo.pyd

build/temp.win32-2.0/Release

contains bingo.obj, bingo.exp and bingo.lib and the .pyd ends up in

build/lib.win32-2.0

however building static dingo.lib for use by bingo

dingo.obj ends up in

build/temp.win32-2.0/dingo and dingo.lib ends up in
build/temp.win32-2.0/

Certainly if I build two .pyds each using different subroutines sub.c
they're going to clash in Release.

>Don't the debug builds have the "_d" suffix ? This should avoid
>any problems with mixing the two.

that may be true, but since we have only one .obj directory don't the
objects clash?

>
>About 3): if your import lib uses the same name as a common
>DLL then your lib should probably use a different name, since
>this would cause problems sooner or later anyway.
>

Currently the linker is presented with the /libpath option before the
objects. seems that M$'s linker is pretty straight forward if I give

link xxx/release/aing.obj xxx/bing.lib /libpath:yyy ....

then a bing.lib from yyy isn't consulted. This isn't safe of course, but
it's clear that static libs which distutils builds should be presented
along with objs before any lib paths and we don't need to use a /libpath
to get to xxx it should be explicit. 

>Unless, of course, I've overlooked something here -- I'm not
>much of a Windows guy ;)
>

-- 
Robin Becker