Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Message-ID: <3D0F798E.70101@ece.gatech.edu>
Date: Tue, 18 Jun 2002 14:18:54 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: cygwin-apps AT cygwin DOT com
Subject: RFD: gettext, iconv, packaging...
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Background:
   the gettext package is currently build without libtool.  The dll's 
are created by hand.  Current dll version is "1" -- e.g. libintl1.dll. 
I've been messing around with gettext-0.11.2 lately, and attempting to 
use the libtool support (after re-libtoolizing with our "devel" version 
of libtool) to build the DLLs.  I have discovered that the new DLL 
version number, as specified by -version-info, is actually "2".

So, I'll need to release a new "libintl2" package to coexist with the 
libintl1 package.  Not a problem.

Discussion:
   However, this would be a good time to change dependencies and things 
(otherwise, if we -- for instance -- LATER add libiconv as a dependency 
of gettext, then we'd need to bump the DLL number again -- and it would 
then be out of sync with the "official" versioning.

So, I propose to
   a) add a libiconv dependency (*)
   b) add a libexpat dependency -- yes, 0.11.2 can use expat if it is there.

(*) Yes, I'll provide/maintain libiconv-1.8.0 -- but I would appreciate 
if someone who has been whining about the lack of libiconv would take 
over maintainership of my zip and unzip packages (Gerrit??).  They are 
low maintainance, but I would like to reduce the total number of 
packages I'm responsible for.  I still feel that, as a non-multilingual, 
latin-alphabet user, I'm not the best person to answer questions about 
using libiconv -- but as long as the package passes its own built-in 
selftests...and heck, I've been "maintaining" the gettext package for 
years.  So, consider this an "ITP: libiconv"

Packaging:
   Bruno included some "packaging hints" in the latest distro.  However, 
they don't really seem to address the issue of two-part libintl shared 
libs, and having multiple versions coexist, or 3rd party packages 
depending on specific versions of the shared lib... He suggests:
   gettext:
     bin/gettext.exe
     bin/ngettext.exe
     man pages for above
     small amount of other docu
     lib/libintl*
     lib/charset.alias
     share/locale/locale.alias
     include/libintl.h

   gettext-tools: requires gettext
     bin/other tools
     other man pages & info & docu
     API docu
     lib/libgettextlib*  (**)
     lib/libgettextsrc*  (**)
     lib/gettext/*
     share/gettext/*
     share/locale/*/LC_MESSAGES/gettext.mo
     share/aclocal/*.m4
     share/emacs/site-list/*

(*) of course, being unix centric, nothing is said about two-part shared 
libs (e.g. we know where libintl.dll.a should go and in which package, 
but nothing is said about cygintl-2.dll).

(**) The "other" tools -- msg*.exe, xgettext, gettextize -- now depend 
on additional libraries, which are built as shared (and static) libs -- 
although the tools are linked dynamically.  These new libs are:
   cyggettextsrc-0.11.2.dll and cyggettextlib-0.11.2.dll
Note that they are NOT versioned according to the -version-info rules; 
they are versioned under the -release 0.11.2 rule.  this is because 
these libraries are NOT for public use.  They are for the use of the 
gettext tools themselves (but are not used by gettext.exe or ngettext.exe).
   This point is further emphasized by the following quote from Bruno in 
PACKAGING:

Note: Although installed by "make install", the static libraries
       $prefix/lib/libgettextlib.a
       $prefix/lib/libgettextsrc.a
don't need to be included in binary distributions; they are redundant.

e.g. nobody but the extra gettext tools themselves links to these libs. 
  Also, their source is not included in packages when you run "gettextize".

What does this mean?  It means that EVERY new release of gettext will 
include new versions of cyggettextsrc*.dll and cyggettextlib*.dll -- but 
there is no need for various versions to coexist.  Just ship these two 
dlls with the exe's that use them -- since it is guaranteed that only 
those specific gettext programs will ever use them; no third parties ever.

So, my packaging proposal for the next release of gettext:

   libintl2:
      bin/cygintl-2.dll

   gettext: requires libintl2
     bin/gettext.exe
     bin/ngettext.exe
     man pages for above
     small amount of other docu
     lib/libintl*
     lib/charset.alias
     share/locale/locale.alias
     include/libintl.h

   gettext-devel: requires gettext and libintl2
     bin/other tools
     bin/cyggettextsrc-0.11.2.dll
     bin/cyggettextlib-0.11.2.dll
     other man pages & info & docu
     API docu
     lib/gettext/*
     share/gettext/*
     share/locale/*/LC_MESSAGES/gettext.mo
     share/aclocal/*.m4
     share/emacs/site-list/*

BUT:
     lib/libgettextlib*
     lib/libgettextsrc*
are NOT included.  Third parties never need to link against them, so all 
we need provide are the dlls.

Changes in my proposal, relative to Bruno's recommendations:
    libintl shared lib gets it own package
    don't ship any import or static libs for libgettextsrc / libgettextlib
    use the name "gettext-devel" instead of "gettext-tools"

Comments/Discussion?

--Chuck