huge library renaming ?

[Patrik Stridvall]

> On Fri, Feb 23, 2001 at 08:31:50PM +0100, Andreas Mohr wrote:
> > Hello all,
> > 
> > one thing that occurred to me:
> > Shouldn't we rename *all* Wine libraries to libwineXXX ?
> > 
> > AFAIR there have been several naming conflicts with other projects
> > (libole, ...), and people who need to remove a previous Wine install
> > from their system manually have a rather hard time...
> > 
> > Any reason for not doing this ?
> > I can't think of any...
> > 
> > If this is a good thing, then we should do this NOW, not 
> when it's too late.

I agree, if we do we must do it before Wine 1.0.
 
> > The current drawbacks are just too much IMHO.
> 
> Why not put them in /usr/lib/wine/ as suggested by the FHS?

I second that.

However I would suggest that we also put symbolic
link to the corresponding files in /usr/lib following
the suggested naming scheme libwineXXX or something
similar.

Other suggestions.
1. libwine_XXX
2. libwin32_XXX

Personal think I would prefer the libwin32_XXX variant
because in theory use could have other implementations 
of the Windows API than Wine and that is of no pariticular
concern of the programmer eventhough of course it is
for the administrator of the system.

If a programmer wanted to use say Win32 filehandling
functions he could, in theory, just link with libwin32_kernel32
and be done with it. Something (in our case Wine) provides it,
but he doesn't care what. This is currently not possible
IIRC but it might be in the future.

Additionally is makes it possible to support both
Win32 and Win64 on 64bit systems like Itanium
by having libwin64_XXX.

This would make it easier to properly link to the files
in Winelib application.

This means you can do 
	gcc -o foo foo.c -lwin32_ole
instead of doing 
	gcc -o foo foo.c -I/usr/lib/wine -lole
that might cause problems if libole.so exist in
another path.

Also not that this also makes it harder to link
to the DLL:s that are not supposed to be use
with Winelib by misstake, like the Win16 DLL:s
since we can choose to not provide symbolic links
to them.