Extending Windows support

[Krasimir Angelov]

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 <eivuokko at gmail.com> 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 at haskell.org
> > http://www.haskell.org/mailman/listinfo/cabal-devel
>