Versioned DLL craziness for mingw-get

While I'll agree with the idea what we have at the moment is a mess
and better still not fully workable.  First, to install a previous
version of a DLL we need the catalogue library packages named with the
DLL version number so that the user could install two differing DLL.
Currently the user can only install version and that wasn't the
intent.

Next we have the development libraries, a developer supporting two
varying projects may need to have two or more varying development
packages of to match the versioned library.  We currently don't have
anything to support that at all.  The upstream packages certainly do
not version the libraries archives.  What I mean is that when
libfoo.dll.a is created the named DLL is stored in this file so we can
only use the named DLL anyway.

Furthermore in trying to develop a method to deliver such versioned I
started with gettext and the most recent version of it contains DLL
that are internal use only; the libgettextlib and libgettextsrc
libraries are versioned after the package version and the library
archive files are delivered in the lib/ directory but there are no
matching header files for them.  I'm thinking that these two library
archive files should not have been delivered.  Also we have files
delivered in lib/gettext, share/gettext and share/aclocal that are
impossible to break into libgettextpo or libintl related.

I am able to name the files that should go to
libgettextpo-0.18.3.1-2-mingw32-dev and libintl-0.18.3.1-2-mingw32-dev
but that left out the lib/gettext, share/gettext and share/aclocal
files so I ended up with a gettext-0.18.3.1-2-mingw32-dev file anyway.
 I put the libgettextlib-0-18-3.dll and libgettextsrc-0.18.3.dll in
with the -bin file since they are not meant for development of other
packages.  I left libgettextsrc.a, libgettextsrc.dll.a libgettextlib.a
and libgettextsrc.dll.a out of delivery since I do not see these as
needing to be delivered.

I suppose I should rename libgettextpo.dll.a to libgettextpo-0.dll.a
and libintl.dll.a to libintl-8.dll.a but then that throws autoconf
into not finding the library files properly and causes issues for the
developer.  Given that the proper versioning isn't happening today to
allow for multiple distribution and given that the development
libraries should also be versioned to allow for delivery.  Also, given
that autoconf would not use the versioned libraries and that there
would be more man hours than anyone has to muster to change the
situation; how can we deliver a proper versioning library system with
mingw-get?  Every single DLL development library would need to
maintain versioning to be effect for multiple versions of that library
to be delivered.

So, even though I agree with the concept; I find in practice that it
is a near impossibility to deliver.  Yes we can rename the packages
for the versioned DLL but that leaves the development libraries not
being versioned and that makes the versioned DLL package name rather
benign in use.

There is one use for DLL versioning while the development libraries
remain with the current DLL and that is applications that require the
older DLL while the new DLL is being refactored in to the production
stream.  However, if this is the reason for breaking out the libraries
into single packages named for the DLL library they represent, there
isn't much reason for that either.  The libraries can still be
delivered in one package named after the primary package name.

I am needing further convincing that DLL versioning within the package
delivery system is worth the time and effort needed to do it.  If we
want to deliver the possibility of multiple dll with different
versions; we need some work in the catalogue to be able to do that.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk