Re: Developing cabal2wix - building Windows installers automatically

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

On 8/6/07, Duncan Coutts 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