Re: Windows DLLs from Unix with minimum effort

[Brian Dessent]

Jason Curl wrote:

> For Posix systems I agree (and I haven't had to care until now). It's an 
> unnecessary burden for w32api however, especially for users that don't have 
> any kind of sane build environment. I guess I'm saying I don't know how to 
> package the result so that someone on w32 can use it on a standard cmd.exe 
> console without having Cygwin, etc. installed. This environment is only 
> necessary for the build. 

The wrapper is totally irrelevant to end users, it is only for the
convenience of the developer to be able to run the binary uninstalled. 
To make a binary package to give to end users you do the exact same
thing that you would on a POSIX system to create a binary package:

make install DESTDIR=/some/staging/area
# or make install prefix=/some/staging/area
(cd /some/staging/area && tar jcf binary-package.tar.bz2 *)

[ aside ]

The choice of whether you use DESTDIR or override prefix is mildly
controversial.  Some hand-written makefiles don't support DESTDIR, and
DESTDIR doesn't play nicely if you're using Win32 paths because you
can't prepend something in front of a drive letter to produce a valid
path.  But if you use automake you automatically get DESTDIR support, so
it's fairly common, as well as being a part of the GNU coding standards
spec.

On the other hand overriding prefix normally doesn't require any special
makefile support, other than the invariant that overriding it must not
cause anything to be rebuilt (which is also specified by the GCS.)  It
also is the only route if you're using Win32 paths since they can't be
prepended.  But I don't personally like it because it becomes clumsy if
you have specified more than just --prefix at configure time (and they
aren't subdirectories of prefix that can use ${prefix}).  For example if
I am making binary packages for a typical distro, I might configure
with:

path/to/configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var

Now I've built and want to install to a staging area in order to create
the binary package.  If I use DESTDIR, I can simply:

make install DESTDIR=/tmp/mypackage

...and the entire tree as originally configured will install under that
staging area.  However if I want to use the override technique I must
remember all of the options that I originally specified and be sure to
override them all appropriately:

make install prefix=/tmp/mypackage/usr sysconfdir=/tmp/mypackage/etc \
        localstatedir=/tmp/mypackage/var

So not only is it more typing, but I've duplicated my configuration in
two places which can easily get out of sync.  This is not a concern in
the common case where only --prefix was given, since all the other paths
have defaults that symbolicly reference $prefix, e.g.
exec-prefix='${prefix}' and bindir='${exec-prefix}/bin' and
libdir='${exec-prefix}/lib' and so on, so they will take the correct
values when only prefix is overridden.  And in fact if you can specify
these as subdirectories of prefix or exec-prefix or whatever it's
advisable to continue to use this syntax so that you can simply override
prefix and have everything else follow.  But as I said I simply find
DESTDIR a cleaner solution that involves less worry.

[ end aside ]

To cater to the typical Win32 user you might want to flatten the
heirarchy, since they are typically used to having everything in one
dir, so e.g. --bindir='${prefix}' --libdir='${prefix}'
--docdir='$[prefix}' (and so on for a million other variables) which
would result in the binary-package.tar.bz2 created above simply being a
flat set of files.  But I guess it all depends on your target audience
and how you plan to distribute things (e.g. NSIS, InnoSetup, 7-zip sfx,
.zip file, whatever.)

> Or should I revert to a different build environment? This is my first attempt 
> at using Autoconf to build something for native Windows (mostly because I 
> want to use it on Linux, but other colleagues of mine benefit from it's use 
> on Windows).

Using Cygwin to build MinGW executables is common but suboptimal. 
Unless you really know what you're doing it's very easy to shoot
yourself in the foot: for example you might leak POSIX paths from the
build/configure system into a header or configuration file (or other
generated file), which the resulting binary will be clueless about since
it's a native MinGW app that only speaks Win32 paths.  I'd recommend
using MinGW+MSYS instead if you don't intend to build Cygwin programs.

Also relocatability is a whole other ball of wax that you have to
address when building for MinGW, because the user expectation is that
they can install the files in any location -- as opposed to Cygwin where
you have a mount table that handles that bit of indirection and presents
a uniform filesystem layout despite the actual location on disk.

Brian