Re: About cabal and compatibility

11 Dec 2005

      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

Re: About cabal and compatibility

Isaac Jones