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.

On Mon, Aug 08, 2005 at 06:59:04PM -0700, Isaac Jones wrote:

I already have a TODO item for adding a flag to "setup sdist" to handle this in a somewhat more fine-grained mannar:

** if there's a flag, --include-preprocessed-sources (or something better) run the preprocessing phase and include both the unpreprocessed and the preprocessed sources in the source tarball?

But really, there are two kinds of preprocessors, as Ross points out. The kind that produce OS-independent code, and the kind that produce OS-dependent code. Perhaps this concept shoudl be added to the PreProcessor type, and a we could have two flags to sdist:

--include-standalone-preprocessed-sources

Which would generate the OS-independent sources from tools like Alex and Happy...

--include-all-preprocessed-sources

Which just includes all of the preprocessed sources as above.

Each additional option complicates the interface. It's far better to make the tool smart enough to choose the right thing, IMO. So instead of --include-standalone-preprocessed-sources, I propose: * preprocessors are annotated with a flag saying whether they are able to produce system- and implementation-independent output (e.g. happy, alex). * for such preprocessors, and if the preprocessor is present, sdist includes the preprocessed output for a CompilerFlavor of Unknown (e.g. happy with no options), in addition to the input. * building a module for which preprocessor input (e.g. Foo.y) is present: if the preprocessor is available, use it with the specific CompilerFlavor (e.g. happy -g). If not, but preprocessed output is available, use that. Otherwise, fail (as now). This will be a awkward with the current scheme of leaving preprocessed output in the source directory, but it was already desirable to change that to keep source directories tidy and simplify setup clean.