Duncan Coutts
On Thu, 2006-07-06 at 15:59 +0100, Duncan Coutts wrote:
Ok, along a similar theme...
We provide the Paths_${projname}.hs module, as a little extra there it provides the current version number. Perhaps we could generalise that and provide the whole cabal file (using the normal Cabal types).
More monologue...
Actually perhaps this isn't such a good idea. It'd tie the version of cabal more strongly to the app it's installing.
Suppose we generate a module using the current version of cabal that's building the package. That has to be the same version as the program gets built against if it's to use this generated module. And then that has to be sufficiently close to the version that the packages was designed to use so that the fields from the cabal package description are the same.
So you're saying that you're worried that the change in the APIs for cabal would make your build system more fragile? I can understand that worry, though the packageDescription type shouldn't change too much, I hope. If we go for something like this, we'll want to go through and make sure that the fields have names that are worthy of being exposed :) I don't understand what you mean here:
Suppose we generate a module using the current version of cabal that's building the package. That has to be the same version as the program gets built against if it's to use this generated module.
If you generate a module during build time and link it in right away, it's going to be the same version of cabal, right? peace, isaac