Robert Dockins writes:

[snip]

...

This would greatly simplify the Distribution.Simple.UserHooks structure bringing it from 34 fields to 14 fields, or so.

Downsides: Making pre and post hooks would now be slightly harder, and it would break existing hooks-using code.

I just want to mention that these kind of changes represent represent a VERY big problem. I discussed that issue at some length in an email I intended to send to this list very recently, but it seems to have gotten lost.

Are you sure they represent a very big problem in practice and not just in theory? The hooks have been a "very experimental" part of Cabal, as the user manual has always said: You can customize the simple build infrastructure using hooks. [...] See Distribution.Simple for the details, but note that this interface is experimental, and likely to change in future releases. I only know of one or two packages that use the hooks. Do you know of backward compatibility problems that cabal has caused? BTW, I just added a "cabal-version" field to cabal so that if a package requires a particular version of cabal, it can say so. Further, my grand plan is that once stuff gets into hackage, we can try making modifications and seeing if it breaks any packages, and if so, offer patches to those package authors (since it's probably eaiser for cabal hackers to write such patches than most package authors). (snip)

I suggest that the cabal team very seriously consider using the Eternal Compatibility in Theory method to manage interface change.

I'll look at this. peace, isaac

Robert Dockins writes:

On Saturday 10 December 2005 07:14 pm, you wrote:

...

Robert Dockins writes: (snip) The Happy build system now does two things that aren't your standard build actions:

1) It creates module which contains the version string before compilation 2) After compilation it runs CPP on a number of template files with various different "-D" options to genreate the parser templates.

I was messing around with doing these using user hooks and I ended up needing to tie pretty deeply into cabal even for the simple task 1).

What I would like to do is to stabalize an interface one of these days. The problem is that, IMO, we need experience with what users want & need in order to stabalize the interface. When writing layered tools like cabal-get, Lemmih had to modify cabal's interface, and when writing cabal-install, I had to modify the interface. But I'll definitely look at the Eternal Compatibility thing!

I have attached my initial attempts so you can see what's happening.

The user hooks change you are talking about would require a complete rework of my Setup.hs file. Its only ~130 lines, but then Happy is a pretty small project.

Not at all. See below.

...

I only know of one or two packages that use the hooks. Do you know of backward compatibility problems that cabal has caused?

No, this is all speculation currently.

...

BTW, I just added a "cabal-version" field to cabal so that if a package requires a particular version of cabal, it can say so.

Well, cabal the library already has to be invoked before the package file is even read! If the Setup.hs doesn't typecheck because the cabal interfaces have changed, you won't even get that far. (snip)

True enough, It's mainly useful for parsing the .cabal file. Setup can't use this information for compiling, but humans can use it to understand compile failures, and cabal-get can use it.

...

Further, my grand plan is that once stuff gets into hackage, we can try making modifications and seeing if it breaks any packages, and if so, offer patches to those package authors (since it's probably eaiser for cabal hackers to write such patches than most package authors).

That depends on the complexity of the build system. In my experience, just trying to figure out what a build system is doing can be pretty difficult. I can't imagine you want to undertake the maintaince of other people's build systems.

I'm certainly not talking about maintaining them, but usually if you modify an interface, the kinds of changes you make are mechanical and repetative.

OTOH, if Cabal is only aiming at pretty simple projects, this may never be an issue.

The plan with cabal was to handle simple projects at first, and add more complex projects as we go along. That's basically happening, and my hope is that we can fix the "simple" interface sooner, and the more complex interface later.

import Data.Version import Control.Exception import System.Cmd import System.IO import System.Exit import System.Directory import Distribution.Setup import Distribution.Simple import Distribution.Simple.Utils import Distribution.Simple.LocalBuildInfo import Distribution.PackageDescription

It would be nice if you used qualified imports so I could see exactly what it is that you need from cabal. Also you'll get better error messages if things disappear.

main = do descFile <- defaultPackageDesc desc <- readPackageDescription descFile let ver = (pkgVersion (package desc)) defaultMainWithHooks (mkHooks desc ver)

mkHooks :: PackageDescription -> Version -> UserHooks mkHooks desc ver = defaultUserHooks { readDesc = return (Just desc) , postConf = doPostConf ver , postBuild = createTemplates , postClean = cleanDerivedFiles }

With the proposed change, all you have to do is something basically like this, not reworking the whole build system:

defaultUserHooks { readDesc = return (Just desc) , confHook = (confHook defaultUserHooks) >> doPostConf ver , buildHook = (buildHook defaultUserHooks) >> createTemplates , cleanHook = (cleanHook) >> cleanDerivedFiles }

(snip)

createVersionModule :: Version -> IO () createVersionModule version = do h <- openFile "src/Version.hs" WriteMode hPutStr h "module Version where\n" hPutStr h ("version = \""++(showVersion version)++"\"") hClose h

That's interesting. I was recently thinking of generating something like CabalInfo.hs which has information like the PackageDescription and the LocalBuildInfo. You would turn on this feature w/ the .cabal file. I'm not sure if any of the information is useful except for the version number, though. We could also add -DPACKAGE_VERSION or something to the cpp line. That would be pretty easy. (snip)

perlRE = "s/^#\\s+(\\d+)\\s+(\\\"[^\\\"]*\\\")/{-# LINE \\1 \\2 #-}/g;s/\\$$(Id:.*)\\$$/\\1/g"

rawSystem "perl" ["-pi.hspp","-e",perlRE,file]

aaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhhh!!!!!!!!! /me runs away ;) But seriously folks, you should check out the new (experimental!) "Program" interface in the CVS / darcs HEAD. The nice thing about it is you can add perl as a Program and configure will find it, and users can say: ./setup configure --with-perl=/my/special/perl. peace, isaac