
Looks ok. A couple of things worry me slightly (I think these were problems before, but your description has highlighted them): - if the package and executables can have different hs-source-dirs and yet share modules, how does this work? Is it sensible? - since the package and each executable can specify different extensions and options, this means in principle we have to compile each module multiple times - it's not safe to re-use the compiled version in the package and executables unless the compiler options are identical. That means not just options-ghc, but also cc-options, includes, and include-dirs. Cheers, Simon On 05 January 2005 11:02, ross@soi.city.ac.uk wrote:
I'd like to propose a refactoring of the package description, as follows:
(1) The unprocessed source tree of every package would contain a package description, consisting a single stanza:
name: unique name of the package (compulsory) version: package version number (compulsory) license: identifier for a common license (compulsory) license-file: name of a file containing the license copyright: copyright holder (compulsory) author: original author of the package maintainer: current maintainer of the package (if different) stability: stability level homepage: URL of the package homepage package-url: (same as homepage?) description: free-text description of the package category: from a list to be specified tested-with: list of compilers and versions (?) build-depends: list of packages needed to build this one exposed-modules: list of modules added by this package executables: list of programs added by this package
(2) Packages using the simple build infrastructure would optionally provide an additional file of build parameters for that infrastructure, consisting of a basic stanza and zero or more executable stanzas:
build-package: Boolean: is package buildable? (default: True) <buildinfo> (for library, if any)
executable: name of a program from executables main-is: relative filename for the main module <buildinfo> (for the executable)
where <buildinfo> consists of:
other-modules: list of additional modules hs-source-dir: name of root directory of the module hierarchy extensions: list of Haskell extensions used by every module options-ghc: additional options for GHC options-hugs: additional options for Hugs options-nhc: additional options for NHC c-sources: list of C source files cc-options: options for the C compiler includes: header files describing foreign imports include-dirs: directories to search for header files ld-options: options for the linker extra-libs: extra libraries to link with extra-lib-dirs: directories to search for libraries frameworks: list of Darwin/MacOS X frameworks to link to
(The options fields are inconsistent -- we can sort that out later.)
This file need not be present until after the pre-conf step; in some cases it will be generated from a template by that step. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Wed, Jan 05, 2005 at 01:08:51PM -0000, Simon Marlow wrote:
Looks ok. A couple of things worry me slightly (I think these were problems before, but your description has highlighted them):
- if the package and executables can have different hs-source-dirs and yet share modules, how does this work? Is it sensible?
- since the package and each executable can specify different extensions and options, this means in principle we have to compile each module multiple times - it's not safe to re-use the compiled version in the package and executables unless the compiler options are identical. That means not just options-ghc, but also cc-options, includes, and include-dirs.
I agree it's a problem, but I think I think it's just between the executables (i.e. the executables should be restricted to the public interface of the library, if any). I'd been assuming that the auxiliary modules used by executables inhabited a common namespace (and this is a common usage pattern), but the varying options do conflict with this.
participants (2)
-
ross@soi.city.ac.uk
-
Simon Marlow