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.
ross@soi.city.ac.uk writes:
(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:
I really don't think that requiring another file is a good idea. Ross & I have been talking in private email about how to get away with using this 2nd file only in the case where it's necessary to perform some external configure step that has to alter a file. I want to keep the burden of extra complexity upon those with complex libraries and tools to package. People with very simple libraries and tools shouldn't have to worry about which fields belong in which files. My proposal was to optionally have the 2nd file (Setup.buildinfo) and to allow it to override the non-required fields or the non-static fields from the 1st file (Setup.description). The file only gets input if the user uses the hooks and defaultMainWithHooks. That said, it's probably a good idea to split up the data types themselves to reflect the distinction between static info and build info. This proposal adds a little complexity to the file parsing, since we have to have this override mechanism (I checked in a prototype a few days ago). This adds a little more complexity for hooks authors, perhaps, but maybe not much if we break up the types the way Ross suggests. But it keeps the complexity where it belongs, and away from Angela, the very simple module Author who just wants to get her tool into Hackage, building on all platforms for all compilers, and who already thinks it's strange that we make her pick a license and write a version number. peace, isaac
participants (2)
-
Isaac Jones -
ross＠soi.city.ac.uk