Re: Extending Windows support

Hi Esa, All these things are really useful for all Windows developers. I didn't yet proposed this only because it is too Windows and GHC specific but this isn't a reason not to have them. Actually if we have support for resources in Cabal then one day I would like to see resource editor in Visual Studio for Haskell. One interesting feature would be to have automatic generation for VERSION resource that to be prepopulated with the version and copyright information from Cabal. We already have generation for one Haskell module why not to have generation for one resource file. You propose to extend the cabal description with one additional stanza type like the executable stanzas but I would recall that the current model with one library and multiple executables is broken. I vote again for a redesign where to have only one library or one executable in a given package. After that with the addition of DLL we will have three types of packages: library, executable or DLL. I didn't looked at implementation but I saw a couple of messages in this mailing list about the introduction of configurations in Cabal. Are they working with executables? Cheers, Krasimir

Esa Ilari Vuokko writes:

...

Hi,

There's few things Cabal could handle for Windows-based Cabal users. I hope to implement them if there's agreement that they are sensible additions into Cabal. All of them can of course be done in Setup.hs, but that's just annoying.

This is rather ghc-specific, because that's what I use. And most of this doesn't probably matter for compilers that aren't producing binaries.

* DLLs Rationale: Building DLLs is fairly common in Windows, they are a most common way to extend many appliations via COM or other plugin-like systems. Note: this has nothing to do with producing dynamically linked haskell packages/libs. Rather it almost identically to producing .exe, except that main won't be called.

Todo: Easiest way seems to be to add new part to package config, much like executables, extending executable-list to contain DLL info might also be doable, but less clean. Important bits I can think of: * passing --mk-dll to ghc * being able to specify .def file and passing it through ghc to dlltool (--optdll--def --optdllPATH/TO/A.DEF) * Possibly building import library by calling dlltool with .def and right options (means we have to add new program: dlltool) * Installing import lib...well dunno about this.

Example how it can be done right now: http://darcs.haskell.org/vshaskell/vs_haskell/Setup.lhs (note that this script builds import lib for diffrent dll than it builds)

* Resource (scripts) Rationale: Resources are embedded (binary) data sections in executables. In Windows these can be (easily) edited after the exectuable has been linked, and there's many APIs that can use them. Also some important information can be encoded in them, like versioning, icons, manifest files. I am not sure about already compiled resource files, I recall some dialogeditors producing object files, but they are probably wrong format object files as long as ghc works on top of gnu toolchain.

Todo: Mainly Cabal needs to know and invoke a tool very much like c-compiler. For mingw (and probably cygwin) this would be windres.exe. We probably also need to get the tool into ghc binary distribution.

Example: I don't know anyone doing this using Cabal.

Best regards, --Esa Ilari Vuokko _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel