Cabal package name patch

Bertram Felgenhauer bertram.felgenhauer at
Sun Jul 30 01:20:44 EDT 2006


Simon's recent changes to the package system have the effect that
cabal-built packages cannot be used. Example error (from lambdabot, using
fps that was previously built using cabal):

    Failed to load interface for `Data.ByteString.Char8':
        Bad interface file: /opt/ghc/lib/fps-0.7/ghc-6.5/Data/ByteString/Char8.hi
            Something is amiss; requested module  fps-0.7:Data.ByteString.Char8 differs from name found in the interface file fps:Data.ByteString.Char8

The attached patch fixes this in Cabal by passing the full package name
(including version) to the -package-name option.  I expect that it breaks
on older ghc versions, and thus should not be applied to the official
darcs repository.
But I hope it's still useful for someone while the underlying issue is
resolved. (Maybe ghc shouldn't be unhappy about this in the first place?)


-------------- next part --------------

New patches:

[use full package version for -package-name
Bertram Felgenhauer <int-e at>**20060730043834] {
hunk ./Distribution/Simple/GHC.hs 65
-import Distribution.Version	( Version(..) )
+import Distribution.Version	( Version(..), showVersion )
hunk ./Distribution/Simple/GHC.hs 137
-              ++ ["-package-name", pkgName (package pkg_descr) ]
+              ++ ["-package-name", pkgName (package pkg_descr) ++ "-" ++ showVersion (pkgVersion (package pkg_descr)) ]


[install: pass the verbose flag to register too
Simon Marlow <simonmar at>**20060728085914] 
[Add documentation of new LocalBuildInfo fields
Duncan Coutts <duncan.coutts at>**20060726230130] 
[Wrap excessively long line
Duncan Coutts <duncan.coutts at>**20060726221702] 
[Hold back on forcing vanilla libs for TH for the moment
Duncan Coutts <duncan.coutts at>**20060726221532
 When we get confirmation from GHC devs that it's the right
 thing to do then we can add it in.
[Add initial support for --enable/disable-library-vanilla flags at**20060720174408
 For additional information see these mail threads:
[build and install cabal-setup as part of GHC build
Simon Marlow <simonmar at>**20060720140417] 
[fix indentation in do block for H'98 compatibility
Malcolm.Wallace at**20060711162221] 
[resolve conflicts from henning-thielemann's work.  Thanks Henning!
ijones at**20060708185016] 
[install Haddock documentation in share/package/doc/html and register that path in the ghc-pkg
cabal at**20060609194058] 
[PackageDescription: haddockName generates the name of the .haddock file
cabal at**20060609193924] 
[PackageDescription: added toMaybe, some logical simplifications
cabal at**20060609193508] 
[Distribution.Simple.Utils: copyDirectoryRecursiveVerbose
cabal at**20060609192715] 
[Distribution.Compat.Directory: added getDirectoryContentsWithoutSpecial
cabal at**20060609192421] 
[Distribution.simple: haddock option --use-package tells which packages to hyperlink to
cabal at**20060605183304] 
[stripPrefix -> dropPrefix
cabal at**20060604195549] 
[generate .haddock interface file when running haddock
cabal at**20060604195216] 
[UNDO: Merge "unrecognized long opt" fix from 6.4.2
Simon Marlow <simonmar at>**20060705142842
 This patch undid the previous patch, "merge from base".  I asked Sven
 to revert it, but didn't get an answer.
 See GHC bug #473.
[Change flags passed to hsc2hs
Duncan Coutts <duncan.coutts at>**20060704001926
 The extra-libraries must be passed as -L-l${lib} or linking the C prog
 that hsc2hs generates may fail if any symbols are referenced.
 Also can't use cppOptions function since hsc2hs doesn't support -U.
 Need to do -U flags in ccOptions seperately.
[finish interaction with remote HTTP servers
audreyt at**20060624233156] 
[stage 2 patch: implement the "list" command
audreyt at**20060624231421] 
[it's now 00-latest not latest
audreyt at**20060624221907] 
[implement support for flat-file layout
audreyt at**20060624221547] 
[parsec is not a dependency
Simon Marlow <simonmar at>**20060518131434
 It is apparently required for the wash2hs test, however.
[Merge "unrecognized long opt" fix from 6.4.2
Sven Panne <sven.panne at>**20060506110640] 
[Cabal.xml: entity greencard was mixed up with haddock
cabal at**20060411161212] 
[Change calls to 'make' into '$(MAKE)'
Duncan Coutts <duncan.coutts at>**20060502174630
 This is the portable thing to do and fixes things on FreeBSD where make/=gmake
[Hugs: copy paths module to the right place, this time
Ross Paterson <ross at>**20060503132510] 
[pass correct -P flag to ffihugs
Ross Paterson <ross at>**20060503122452
 The -P flag wasn't superfluous, but it was wrong for executables.
[Hugs: copy path module into package build dir
Ross Paterson <ross at>**20060503122300] 
[add header file for GetModuleFileNameA
Ross Paterson <ross at>**20060502141641] 
[remove superfluous ffihugs -P option
Ross Paterson <ross at>**20060502104635] 
[fix for Hugs
Ross Paterson <ross at>**20060502101054
 Add explicit types for a couple of constants to work around Hugs's
 imperfect implementation of the monomorphism restriction.
[TAG 1.1.4
duncan.coutts at**20060502095901] 
[TAG shipped in GHC 6.4.2
Simon Marlow <simonmar at>**20060424093133] 
[Hugs: also compile the paths module
Ross Paterson <ross at>**20060501171206] 
[markup fix
Ross Paterson <ross at>**20060501145015] 
[move cabal-install/etc-cabal-get to cabal-install/etc-cabal-install
alson at**20060430175158] 
[Complete move of cabal-get to cabal-install + some fixups
alson at**20060430174300] 
[basic information for installing
ijones at**20060430063205] 
[build and install cabal-setup
ijones at**20060430063144] 
[add etc-cabal-get as a data-file
ijones at**20060430055332] 
[bumping cabal version number. 1.1.4 will be the one released with ghc 6.4.2.
ijones at**20060430044905] 
[modify makefile for cabal-install
ijones at**20060430041617] 
[cabal-get will become cabal-install
ijones at**20060430025633] 
[getting rid of cabal-install in favor of cabal-get
ijones at**20060430024951] 
[Remove erroneous exports...
alson at**20060428195702] 
[Patch to fix "-ixyz" being overwritten by "-i" and to remove Cabal's dependency on the Cabal package.
alson at**20060428055353] 
[Separate build into "make build" and "make install"
alson at**20060428034151] 
[Fixups to get cabal-get into Cabal
alson at**20060428032617] 
[Update Cabal with cabal-get
alson at**20060427204050] 
[Fix JHC command lines.
Einar Karttunen <ekarttun at>**20060427005922] 
[document install-includes and register --inplace
Simon Marlow <simonmar at>**20060428130542] 
[fix imports for Windows
simonmar at**20060428075617] 
[Better support for packages that need to install header files
Simon Marlow <simonmar at>**20060426140627
 There's a new field for .cabal files: 
      install-includes: foo.h bar.h
 This means the same as 'includes', except that the files named therein
 will be installed into $libdir/include.  'includes' should only be
 used for headers already installed on the system.
 Directories listed in 'include-dirs' still turn into -I options for
 hsc2hs, cpphs, and C compilations.  However, for installation
 purposes, relative directories in 'include-dirs' are now treated
 differently from absolute directories:
   - an absolute directory is copied to the include-dirs field
     of the installed package config
   - files names in install-includes are assumed to be found in
     one of the *relative* directories listed in include-dirs
 So the common pattern for providing a header file that you want to
 be available everywhere including to via-C compilations against this
   include-dirs: myincludes
   install-includes: foo.h
 will install the header file myincludes/foo.h in
[merge from base:
Simon Marlow <simonmar at>**20060426121408
 Wed Apr 26 13:11:10 BST 2006  Simon Marlow <simonmar at>
   * RequireOrder: do not collect unrecognised options after a non-opt
[pass unrecognised options before the command name to the command
Simon Marlow <simonmar at>**20060426121321
 Previously, options before the command name other than --help were
 just ignored, which is quite confusing behaviour.  So now,
 ./setup --with-compiler=ghc-6.4.2 configure
 works as you expect, instead of ignoring the --with-compiler option.
[First attempt at a cabal-setup command
Simon Marlow <simonmar at>**20060303162233
 cabal-setup is a replacement for 'runhaskell Setup.hs'.  It accepts
 exactly the same commands.  Additionally, the following new features
 are provided:
  * Setup.{hs,lhs} is optional.  If omitted, cabal-setup behaves just
    like Distribution.Simple.defaultMain.
  * If the .cabal file contains a cabal-version field, then Setup.hs
    is built using an appropriate version of Cabal.  This might entail
    creating Setup.hs if it doesn't exist.
  * cabal-setup interprets the options --with-compiler and --with-hc-pkg
    to determine the compiler used to compile Setup.hs.
 Later, we could add support for building multiple packages in
 dependency order, as per recent discussions on libraries at
[add new modules
Ross Paterson <ross at>**20060425195548] 
[Implement "setup register --inplace", and a few other minor things
Simon Marlow <simonmar at>**20060425144733
 There are a few changes in this patch:
    - New flag to register, --inplace.  "setup register --inplace"
      registers the package for use in the build tree, i.e. without
      installing.  It works with GHC only, currently.
    - The parameters to RegisterCmd, UnregisterCmd and InstallCmd are a
      legacy from before the time of hooks (or something) and don't
      serve any purpose any more, AFAICT.  So I removed them.
    - I don't think "setup register" worked propertly before if
      --user was given to configure.  It does now.
    - New flag to register: --with-hc-pkg (just the same as when
      given to configure, but lets you override it at register-time)
[Refactoring only: separate compiler-specific simple build implementation
Simon Marlow <simonmar at>**20060425111957] 
[get LocalBuildInfo from Distribution.LocalBuildInfo
Simon Marlow <simonmar at>**20060425111921] 
[warning cleanup
Simon Marlow <simonmar at>**20060425102302] 
[Distribution.Compat.FilePath should be hidden
Simon Marlow <simonmar at>**20060411141305
 This also matches
[Hide Distribution.GetOpt; it just re-exports System.Console.GetOpt anyway
Simon Marlow <simonmar at>**20060411141045
 This also matches Cabal.cabal.
[GHC FFI flag should be -fffi not -ffi, the latter merely happens to work.
Duncan Coutts <duncan.coutts at>**20060318022010] 
[Make ghc-6.2 packages be exposed by default.
Duncan Coutts <duncan.coutts at>**20060221135026
 For ghc-6.4 when Cabal registers packages it exposes them by default.
 However it does not do the same fo ghc-6.2. This change corrects the
 discrepancy. This patch is already being used in Gentoo with Cabal 1.1.3.
[test case for buildinfo with multiple executables
ijones at**20060408213048] 
[It is no longer necessary to run 'configure' before 'clean' or 'sdist', addressing
Nick Alexander <ncalexan at>**20060404054127
 In order to change this behaviour, it was necessary to modify the hook interface, specifically cleanHook, postClean, sDistHook, postSDist.  They now take a Maybe LocalBuildInfo, since a LocalBuildInfo might not be available in .setup-config.
[windows patch from brian.mabry.edwards at
ijones at**20060404171731] 
[oops, don't enable -split-objs by default
Simon Marlow <simonmar at>**20060314124358] 
[export configDependency
Simon Marlow <simonmar at>**20060303155527] 
[comment fix
Simon Marlow <simonmar at>**20060303155516] 
[don't check cabal-version during parsing, it doesn't work
Simon Marlow <simonmar at>**20060303155500
 because parsers are evaluated multiple times due to backtracking.
[no need to use a verbatim copy of System.Console.GetOpt, omit if possible
Simon Marlow <simonmar at>**20060303144025] 
[Support for -split-objs with GHC
Simon Marlow <simonmar at>**20060302170907
 New configure option: --enable-split-objs creates libraries using
 -split-objs with GHC (current HEAD or later only, the configure checks
 for version 6.5).  Fixes ticket #19.
[Initial support for JHC
Einar Karttunen <ekarttun at>**20060206233543] 
[added some fields to test suite for duncan's mods
ijones at**20060204223256] 
[fixup PackageDescription test code
Duncan Coutts <duncan.coutts at>**20060201183912
 just ignore the extra ParseOk warnings field
[ignore "x-" extension fields without a warning
Duncan Coutts <duncan.coutts at>**20060201183145] 
[Make unknown fields a warning rather than an error
Duncan Coutts <duncan.coutts at>**20060201182944
 Add support for warnings to the ParseResult type. Change existing
 warnings from using Debug.Trace to use this new warning support.
[fix conflict
Simon Marlow <simonmar at>**20060206095833] 
[push and pull all
ijones at**20060201185441] 
[combine GNUmakefile and Makefile
Simon Marlow <simonmar at>**20060206095400] 
[now build Setup.lhs instead of using runghc on it. still uses runhugs.
ijones at**20060130054810] 
[cabal-install uses defaultMain if it can't find Setup.lhs
ijones at**20060130050710] 
[cleaned up suffix handler params to hooks
ijones at**20060116064811
 Summary if last few changes: I modified the hooks interface quite a
 bit, again.  There's good news and bad news about this.  The good news
 is that it's cleaned up and should be easier to maintain and to avoid
 future modifications.  The bad news is that this change itself will
 break stuff, of course.
 If you have any trouble building your Setup scripts, please let me
 know.  I really think that it was best to bite the bullet right now in
 one big go instead of down the road with lots of little changes.  I
 have a lot more confidence in the hooks interface, and I don't
 actually expect that it'll change as often.
 I made the types more consistent, and made sure there are accessor
 functions on each of the Flags types so that if the flags types change
 in the future, it shouldn't break lots of code.
 Another piece of good / bad news is that I decided not to get rid of
 the pre & post hooks.  They are nice for convenience and it wouldn't
 be nearly so easy to write hooks without them.
 That's bad because the interface to hooks is still pretty big, which
 means that there's more likelihood that it'll change in the future.
 Another weakness in the Hooks interface is that with command hooks
 (like sDistHook) it's tempting to add parameters to them; basically
 the stuff that we compute between the preSDist and sDist hook.  I
 removed such params and have their values computed elsewhere.
 Cabal hackers, please avoid adding parameters to these command hooks
 if at all possible in order to keep the interface steady.  If you need
 to compute a value to pass to these functions, compute it in the
 function and / or make it available as a function that someone
 crafting hooks can use as well, or consider whether it belongs in one
 of the parameters already being passed to the hooks,
 PackageDescription, LocalBuildInfo, UserHooks, Flags.
[make the order of params to cmd hooks consistent
ijones at**20060116055858] 
[remove some flags from sdist, some cleanup
ijones at**20060116053818] 
[clarifying and making flags types consistent
ijones at**20060116035033] 
[changing tuple types to records w/ fields
ijones at**20060115234317] 
[moving TODO stuff to wiki
ijones at**20060115234303] 
[fix version number in fptools makefile to match .cabal file
ijones at**20060201183331] 
[Add extraGHCiLibraries to the InstalledPackageInfo and extend the parser.
Duncan Coutts <duncan.coutts at>**20060131163640] 
[re-add the GNUmakefiles
Simon Marlow <simonmar at>*-20060123115236
 These are now safe after we added "-f Makefile" to the make args when invoked
 from the GHC build system.  This repo should now be useable as the main
 Cabal repo.
[re-add the GNUmakefiles
Simon Marlow <simonmar at>**20060123115236
 These are now safe after we added "-f Makefile" to the make args when invoked
 from the GHC build system.  This repo should now be useable as the main
 Cabal repo.
[TAG checkpoint
simonmar at**20060113152542] 
Patch bundle hash:

More information about the cabal-devel mailing list