[Distutils] libraries options

[M.-A. Lemburg]

Robin Becker wrote:
> 
> 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?

I guess so. 

Would it be hard to move all objects and libs into
the Release/Debug dirs, rather than keeping them in the top-level
build directory ?

I am not sure about the consequences of making this change, 
but since we're in control here (distutils is building the
command line, so we can fiddle with it in any way we want to),
we can easily leverage any problems this might cause by adding
some explicit paths.

Could you submit a patch for this ?

> >
> >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
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company:                                        http://www.egenix.com/
Consulting:                                    http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/