Developing cabal2wix - building Windows installers automatically

[Duncan Coutts]

On Tue, 2007-08-07 at 16:22 +0300, Esa Ilari Vuokko wrote:

> On 8/6/07, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> > On Mon, 2007-08-06 at 01:05 +0300, Esa Ilari Vuokko wrote:
> > > Issue 2:
> > >  setup copy --destdir=foo is confusing in Windows.  If my prefix is
> > > c:\Program Files (like it is if I run configure without options),
> > > the directory structure after copy is foo\Program Files - ie. unsuable
> > > locally because drive letter is missing,
> >
> > It's not clear that's true, if you copy the files in foo\Program Files\
> > to C:\Program Files\ and register the package with ghc-pkg then it
> > should work fine.
> 
> Yeah, but unlike unix, information is lost, and some of it is system
> dependent.  Hence setup copy dist feel so very wrong in Windows.

I don't really understand this. Sure having a Program File prefix in
your image directory is useless, so you want --prefix=. to get no extra
prefix.

But the concept of an install image is not at all useless. That's what
all build systems give you, on windows or other systems. I've worked
with windows installers before and the modus operandi is to start from
an install image generated by the build system. That's what setup copy
is for - for generating an install image.

> > >  and unusable at remote
> > > locations, because Program Files is not localized.
> > >  I'd like not to use all possible directory flags at configure time,
> > > because it is impossible to know how different packages react to them.
> >
> > I'm not sure why you say that; what they mean does not vary between
> > packages. I think setting the prefix and other directory flags should be
> > fine.
> 
> If that's a rule for packages, I'll go with it.  There is no such guarantee
> in Setup script. 

If they're using the Simple build system (and almost all packages do)
then you know that the directory flags to the same thing.

> It also forces me to duplicate Cabal's logic on directory structure.

I don't understand this.

> > > Suggestion: Make copy-hook unable to copy random files on their own,
> > > this way there could be setup copy --list-links, which would be
> > > nicer, IMHO.  As the list could also differentiate between different
> > > types of files.  Profiling lib, shared libs (dev and end-user
> > > installer in one.)
> >
> > I don't think it's a problem that cabal doesn't support this since it's
> > easy to generate an install image by copying into a temp dir. This is
> > the way most other build systems work (both unix and windows ones). All
> > you'd be saving is one bunch of file copies which is really pretty
> > cheap.
> 
> Space is not my concern at all in this.  It's the akwardness.  setup copy
> clearly works because that's how unix files are typically organised.
> It typically seems clunky from Windows perspective.

If the install image is not laid out to your liking then it can be
modified by overriding the various directory flags in the configure
step. It may well be that these defaults are not yet right for windows
or that there is insufficient flexibility in being able to modify the
directories for particular kinds of files. Those are things we can fix.

> I'd also really like to know what each files does.  Are they executables,
> libraries (and what kind!), interface file, etc.

The way cabal (and other build systems) deal with this is that instead
of identifying what each file is, they allow you to specify where
various kinds of files should go. At the moment that's not sufficiently
fine grained even for unix systems (eg we'd like to set docs
independently from data files). You may also need more fine grained
distinctions for Windows. Tell us what distinctions you need to make
that you can't make at the moment, or better, tell us what you expect
the install image to look like.

> > You an do that by calling functions in the Simple build system.
> 
> Yes.  I use read instance provided for LocalBuildInfo.
> 
> It still will break if setup is built against cabal that has changed
> LocalBuildInfo structure AFAICT.

Yes. This will happen frequently.

Hmm, for packages that don't need hooks you could do the whole build
using the cabal api and you'd have no problems, but for ones that use
Setup.hs it's harder.

Duncan