package descriptions

[Simon Marlow]

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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries