Add "tools" field (like "extensions")

[bos]

(Imported from Trac #132, reported by guest on 2007-05-26)

Add a "tools" field, similar to the "extensions" field. Would contains things like happy, alex, hsc2hs.

How should it cope with some generated files (happy/alex) being in the source tarball, but others (hsc2hs) not?

What about cpp? Should it be a tool as well as an extension?

[bos]

(Imported comment by @dcoutts on 2007-05-26)

(random comment from myself on a mailing list)

The problem is that currently .cabal files to not specify what build tools they need, so Cabal has to look for all the possible tools it knows about before it finds out if any of them will be needed. This is because at the moment it has to check for these tools in the configure step, but currently it only finds out if it needs the tools in the build phase.

The right thing to do is to have proper dep resolution that works out what tools are needed and it should tell the developer to record this in the .cabal file in a new build tools dependency field. They do have to be recorded in the .cabal file because it's impossible for the dep resolution to discover the build tools required in the configure step without actually running some of those build tools, which obviously should not happen in the configure step. So the best we can do is tell developers when they've missed a tool.

Then once they're recorded in the .cabal file it'll be easy to avoid looking for and warning about build tools that are not required.

[bos]

(Imported comment by @dcoutts on 2007-07-05)

So I've added a "build-tools:" field. However I've added it to the top level part of the cabal package structure where really it should be part of the library and executable sections. I couldn't figure out how to do that though, I'm hoping Thomas will fix that for me :-)

So it allows version ranges too, and it uses the Program infrastructure to check for these being satisfied. It rejects programs that are not known to Cabal (note that the known programs can be extended by via the hooks in a Setup.hs script).

This does not address the question about pre-generated pre-processor output included in sdist tarballs.

As for the cpp issue, the build-tools refers to a specific program, so it's not for the general notion of requiring C style pre-processing. So I think CPP is an extension, and ghc, cpp and cpphs are possible programs that cabal may choose to implement the CPP language extension. So in fact Cabal does not even know about the "cpp" program as it uses ghc or cpphs.

[bos]

(Imported comment by @dcoutts on 2007-08-23)

Now documented too.