package description fields

[Ross Paterson]

On Wed, Aug 03, 2005 at 07:27:01PM -0500, Brian Smith wrote:
> On 8/3/05, Ross Paterson <ross at soi.city.ac.uk> wrote:
> > 1) New field extra-tmp-files, a list of extra files to be removed by
> >    setup clean, beyond those that can be deduced.
> 
> What is the use case for this? Temporary files are either created by
> tools Cabal already "knows" about (GHC, hsc2hs, etc.), or they are
> created by hooks. It seems like Cabal should know enough to clean
> temporary files created by the tools it invokes. If the user writes a
> hook that generates temporary files, then they should also write a
> pre/-post-clean hook to delete them.

Indeed, these would be files created by hooks, e.g. the postConf hook
in defaultUserHooks.  The purpose of the field would be to avoid the need
for another hook.  For that particular hook (e.g. using an autoconf-based
configure), it's not feasible to put the temporary files inside dist.

> > 3) New field data-files, a list of files to be copied to a place where
> >    an executable can find them (e.g. template-hsc.h for hsc2hs):
> >         Hugs: the directory containing the Main module
> >         GHC/Windows: the directory containing the executable
> >         GHC/Unix: /usr/local/share/<exename>
> >    plus a new function in System.Directory to return the name of this
> >    directory.  That would address Dimitry's requirements in
> 
> How about allowing directories too, which would be copied recursively?

No objection to that.

> What would the paths in data-files be relative to?

All file names mentioned in a .cabal file are relative to the root of
the package source tree, i.e. the directory containing the .cabal file.
But I had in mind that if you had

	data-files: include/template_hsc.h

that template_hsc.h would be copied to a file of that name relative to
the package data directory (not under include).

> BTW, what exactly is a "source distribution?" I think a very
> reasonable definition is "A source distribution can be built with
> nothing more than a Haskell compiler/interpreter that supports the
> required language features and that has the correct packages and
> libraries installed" In particular, a source distribution would never
> require any preprocessors.

That wouldn't do -- a source distribution must be system- and
implementation-independent.  That means you can't include the output of
hsc2hs or cpphs, for example.  Preprocessors like happy and alex are
a different case: they can produce implementation-independent output,
which would be useful on systems without these programs, but they can
also produce versions that take advantage of GHC features.  In such
cases, if a package contained the implementation-independent output as
well as the preprocessor input, it might be useful for Cabal to use the
preprocessor if available and the packaged output if it wasn't.