Re: [lmi] Cygwin installation

[Greg Chicares]

On 2007-07-24 15:41Z, Greg Chicares wrote:
> It's time to overhaul the msw programming environment we use
> for production

Although we're scheduled to finish this early next year, I've
been able to make substantial progress in my free time lately.
We've tested the following instructions on several msw machines.

Install Cygwin according to steps zero through fifteen in the
original email here:
  http://lists.nongnu.org/archive/html/lmi/2007-07/msg00008.html

Save this file
  http://cvs.savannah.nongnu.org/viewvc/lmi/gwc/install_msw.sh?root=lmi
to 'C:\cygwin\tmp'. (Eventually I'll store it elsewhere.)

Click the Cygwin icon to start 'bash', then type
  cd /tmp
  ./install_msw >log 2>&1

That's all there is to it. That script downloads and builds the
source code for lmi and all the libraries it depends on.

It works today, but it's not yet of production quality. Some of
the code is ugly, and some of it isn't sufficiently robust: for
example, it won't work from behind a firewall that blocks pserver
access. We'll add and test more code to download and install data
files such as mortality tables, and ancillary programs such as
apache's fop (for creating pdf output); but that stuff is all
pretty straightforward, and we've cracked the hardest nuts first.

Here's my rationale for some of the technical decisions. First of
all, at least for now, I've chosen to use a MinGW toolchain in a
Cygwin environment. The main reason is that we can choose any
version of each component in the MinGW toolchain--whereas Cygwin
typically offers only one "current" and one "previous" version,
which may change outside our control. This poses an issue:

  what cygwin sh sees      what mingw gcc sees
       /x/y                     C:/cygwin/x/y
       /cygdrive/c/x/y          C:/x/y

One way to make this work is to use wrappers, e.g.:
  http://sourceware.org/ml/binutils/2006-12/msg00256.html
  http://cygwin.com/ml/cygwin/2006-01/msg01459.html
  http://cvs.winehq.com/cvsweb/wine/tools/Attic/winegcc.c?rev=1.16
but there seems to be no widely-used, debugged set of wrappers.
Instead, I chose to mount "C:/opt/lmi" as "/opt/lmi": that's
the easiest way to let MinGW gcc and Cygwin utilities refer to
the same file by the same path.

For consistency with that decision, I chose to configure and
build libraries with prefix='/opt/lmi/local'. That seems
appropriate especially because we use nonstandard parameters,
so our builds of these libraries might not be ideally suited
for other programs anyway. But few potential users would wish
to build other msw programs that use these libraries.

This approach is deliberately conservative. At this time, we're
replacing only the shell and command-line utilities. After we've
got that completely stabilized, we can consider switching to
Cygwin gcc (without '-mno-cygwin'); that would mean we'd get
the gnome xml libraries (and others) for free, but we'd also
have to look out for 'newlib' issues, and we'd probably have a
problem with native paths. We'll take it one step at a time.

And automating the installation of an msw build environment is
one big step. It looks like the thorniest issue is installing
Cygwin: its 'setup.exe' GUI requires human interaction, there
seem to be problems with broken mirrors, and so on. Let's post
the problems we encounter and the solutions we find right here.