Re: package description fields

On Wed, Aug 03, 2005 at 07:27:01PM -0500, Brian Smith wrote:

On 8/3/05, Ross Paterson 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.