Packaging DLLs for cygwin [was Re: readline maintainer]

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

I've changed the subject line for the search engines, because there's a 
halfway-coherent description concerning packaging DLLs for cygwin, below.

Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The patch below is needed if bash is to dynamically link against readline.
>   It adds the same hack I used in the static link to work around the
> double-character prompt printing bug (the bug has been reported upstream,
> but no official answer has been made).  It also adds an additional hook so
> that bash can override getenv(), fixing not only tilde-expansion, but
> several other environment variables that readline tries to read.

I've uploaded 5.0-3 and marked it 'test' so give it a shot.

> Charles, since readline and bash are so intricately related (and have the
> same upstream maintainer), would you be willing to relinquish
> maintainership of the various readline packages to me?  I've never
> packaged anything with a .dll before, but hopefully I can learn it quickly
> from the existing setup.

Sure, you can have it.  (What, ME complain about LESS work?)  Take a 
look at the readline-5.0-3-src package, and see what you think about it. 
 If you have questions or need any help before the next release, ask 
away (offline).  But, as far as I am concerned, once I promote 
readline-5.0-3  from test to current (give that about a week), readline 
is yours.

Unless you look at the packaging script and run screaming for the hills.

Obviously you've seen the patches in the current source package.  What 
you will probably notice is that readline takes a rather "brute force" 
approach to building shared libraries -- and my patches (to Makefile.in, 
configure.in, and shlib/shobj-conf) are DEFINITELY brute force.  (e.g. 
they break compilation on other platforms, so Chet wouldn't even think 
about accepting them AS-IS.)

But, it's worked fairly smoothly now for a while, and the Make/configure 
 changes aren't difficult to maintain out-of-tree.  (I should have been 
more proactive about pushing back "our" changes to the actual source 
code, tho).  Also, I'm using Chet's "official" readline50-NNN patches, 
but I'm keeping them separate from "our" packages, so I've modified the 
build script a bit (see the "fixup()" function).  Also note the 'move 
libtermlib.a out of the way' junk in prep() and finish().

Now, about DLL packages: typically, a package which provides DLLs would 
do something like

libfooN-5.0-3.tar.bz2
  contains /usr/bin/cygfoo-N.dll
  setup.hint would specify 'external-source: foo'
libfoo-devel-5.0-3.tar.bz2 (no 'N')
  contains /usr/lib/ libraries, and /usr/include/ headers
  maybe some other stuff
  setup.hint would 'require' libfooN
  setup.hint would specify 'external-source: foo'
foo-5.0-3.tar.bz2
  contains executables and other stuff that's not 'devel'
  setup.hint would 'require' libfooN

Documentation is usually split between the "main" package 'foo' and the 
"devel" package 'libfoo-devel' however it seems appropriate.

However, in readline, *everything* is devel except for a few executables 
nobody ever uses.  SO, in my readline, I combined the "devel" and "main" 
packages into "main".

Also, my DLL package ('libreadline6', currently) contains TWO DLLs 
(cygreadline6.dll and cyghistory6.dll) which is rather unusual.

Oh -- one other thing: with DLL packages, if you ever bump the DLL 
number (and release, say, libreadline7-6.0-1), things get wierd.  When 
you have multible binary packages from one -src, all but one of the 
binary packages will have a setup.hint file that specifies 
'external-source: foo' where the -src package is foo-VER-REL-src.tar.bz2.

So, fine...you do that.  But now, project forward after a few more 
releases.  You've got a bunch of -src package for your -6.0-X series, 
but eventually all the -src packages that libreadline6  was specifying 
with 'external-source:' go away.  Big problem.  GPL violation.  Bad news.

So to avoid this problem, immediately upon bumping the DLL num, you
  (1) make a copy of readline-OLDVER-OLDREL-src.tar.bz2 and call it 
libreadlineN-OLDVER-OLDREL-src.tar.bz2
  (2) remove the external-source line from the obsoleted DLL's setup.hint.

We've already done this at least twice for readline: libreadline4 and 
libreadline5.  See dir listing from the ftp server, below:

..../readline/:
libreadline4/
libreadline5/
libreadline6/
readline-5.0-1-src.tar.bz2
readline-5.0-1.tar.bz2
readline-5.0-2-src.tar.bz2
readline-5.0-2.tar.bz2
readline-5.0-3-src.tar.bz2
readline-5.0-3.tar.bz2
setup.hint

..../readline/libreadline4:
libreadline4-4.1-2-src.tar.bz2   <<- copy of readline-4.1-2-src.tar.bz2
libreadline4-4.1-2.tar.bz2
setup.hint                       <<- no more 'external-source'

..../readline/libreadline5:
libreadline5-4.3-5-src.tar.bz2   <<- copy of readline-4.3-5-src.tar.bz2
libreadline5-4.3-5.tar.bz2
setup.hint                       <<- no more 'external-source'

..../readline/libreadline6:
libreadline6-5.0-1.tar.bz2
libreadline6-5.0-2.tar.bz2
libreadline6-5.0-3.tar.bz2
setup.hint                       <<- 'external-source: readline'

Yeah, it's a pain.  So why would you bump the DLL number?  When the 
exported interface has changed in a way that is NOT backwards 
compatible.  E.g. an existing entry-point (function or exported DATA 
item) was removed, or the signature or type of an existing entry-point 
was changed.  Or there was some outside-your-control ABI issue -- I once 
bumped the DLL number because of the cygwin-1.3.x--->1.5.x 64bitIO change.

Hope that helps; thanks for taking readline off my hands; and feel free 
to ask questions offline if you run into problems.

--
Chuck