needing to know install paths

Isaac Jones ijones at syntaxpolice.org
Sat Jul 8 13:51:49 EDT 2006


Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:

> 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


More information about the cabal-devel mailing list