Re: gtk & vs8

[Tor Lillqvist <tml iki fi>]

(CCing to gtk-devel-list, please subscribe to that list and follow up
there.)

 > Anyway as you may or may not know, vc8 has this side by side (SxS)
 > "feature" for dlls.

I have heard of this term, but haven't investigated more closely what
it means.

 > Briefly, it finally allows for simultaneous different version of 
 > libraries to be installed, almost like unix with way more
 > complexity.

Hmm. As long as you haven't installed any DLLs in the Windows System32
folder (which hasn't been rcommended/approved for a long time), the
way DLL lookup traditionally works on Windows has already been pretty
much like on Unix in my opinion?

It has always been possible to have several versions of libraries that
offer identically named DLLs installed just fine, in separate
locations, as long as you don't get confused and know what you are
doing. (Of course, end-users typically easily get confused, don't know
what they are doing, and desperately start copying DLLs here and
there, messing things up completely...) How you set your PATH when
invoking some EXE directs where the DLLs are looked for, quite closely
corresponding to how LD_LIBRARY_PATH works on ELF-based Unix systems.

How does this side-by-side feature affect the fact that a run-time
installation of GTK+, Pango and many other libraries consist of not
only the DLLs, but a lot of other files as well? Also, for instance
Pango and GTK+ have several DLLs that should be in the very same
folder, does side-by-side allow that?

All libraries that I have ported look up their full pathname at
run-time and deduce their installation location from that, to know
where to look for the other files. If the last component of the folder
where the DLL is located is called "bin", the parent folder of that is
assumed to be the root of the installation, otherwise the folder where
the DLL is itself is assumed to be the installation root. The paths to
the other files are then formed starting from this root.

Can one have a potentially quite extensive subtree of of other files
under the folder where a side-by-side installation of a DLL is? Can
there be several DLLs belonging to the same product (like the Pango
DLLs) in the same folder?

 > So I was just wondering if you had any thoughts on this, or perhapes 
 > have already done it.

Other than what I now write in this message, nope, sorry, as I don't
really know side-by-side technology yet.

BTW, I hope you understand that you *should* use different names for
the DLLs when you build them against another runtime than msvcrt.dll?

The VS8 project files for GLib use the naming convention
libFOO-vs8.dll while the standard, msvcrt-dll -using DLLs as built by
GNU tools or MSVC6 are called libFOO.dll. For instance
libglib-2.0-0-vs8.dll and libglib-2.0-0.dll.

I don't know if the person who contributed those VS8 project files use
any side-by-side methods to deploy what he built, at least I don't
recall him mentioning anything about that. Probably you should use
some other unique naming convention for your DLLs, for instance
libFOO-vs8-sxs.dll? You coult even drop the "lib" prefix and "2.0" and
"-0" parts of the DLL names, as those are mostly artefacts of Unixish
conventions, and the side-by-side methods are very far from Unix
anyway. What would you think of using DLL names like glib-vs8-sxs.dll?

The existing VS8 project files are in the build/win32/vs8 subfolder of
GLib 2.12.6 and earlier sources. Unfortunately they are not present in
GLib 2.12.{7,9,10,11} sources as "build" is a separate module in the
version control system. It was included in GLib when CVS was used, but
now SVN is used and it doesn't have an identical inclusion mechanism,
and we haven't yet decided how to handle this. I guess I could just
move the "build" files into GLib and delete the separate "build"
module.

--tml