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