This project is mirrored from Pull mirroring updated .
  1. 28 Apr, 2008 1 commit
  2. 26 Apr, 2008 1 commit
    •'s avatar
      Fix fix for #224. · 7e69b6f4 authored
      Changing from list of Dependencies to Maps resulted in the wrong Monoid 
      instance being used.  I'd still like to be able to run a test suite on 
      this but that'd require a lot more work to do properly...
  3. 23 Apr, 2008 5 commits
    • Duncan Coutts's avatar
      When multiple specifying list fields in the same section combine them · 48c8903b
      Duncan Coutts authored
      eg if you had:
      extensions: Foo
      extensions: Bar, Baz
      then previously we only ended up with [Bar, Baz]. Now we get them all.
      Only applies to list fields, for single fields the second value is taken
      and the first is silently discarded. This isn't good of course but the
      fix is harder since we're not in a context where we can report errors.
      Really we should just declare up front what kind of field it is and
      inherit the right behaviour automagically, either duplicates disallowed
      or allowed and combined with mappend.
    • Duncan Coutts's avatar
      Normalise file names in warning messages · 9d3299ad
      Duncan Coutts authored
      We already do this for error messages.
    • Duncan Coutts's avatar
      Fix the check for -XFooBar ghc-options flags to be more permissive · eb148937
      Duncan Coutts authored
      Previously we rejected all such flags but that posed the problem that older
      versions of Cabal, like 1.1.6 did not understand new extensions so we
      could not actually follow the advice and use the extenion. So now we only
      warn about -X flags if they refer to old extensions that Cabal 1.1.6 knew
      about. If the .cabal file specifies cabal-version: >= 1.2 or similar
      (anything that excludes 1.1.6) then we warn about all -X flags.
    • Duncan Coutts's avatar
      Add checks for unknown OS Arch and Compiler names · 99ec2dca
      Duncan Coutts authored
      They're ok locally but for distribution they need to be known.
    • Duncan Coutts's avatar
      Package check now take a GenericPackageDescription · 87ec8824
      Duncan Coutts authored
      Unfortunately in some cases we only have a already-configured
      PackageDescription to we have to expose a checkConfiguredPackage.
      We should refactor things so that we keep all the information
      even in a configured PackageDescription.
  4. 22 Apr, 2008 3 commits
  5. 20 Apr, 2008 2 commits
    • Duncan Coutts's avatar
      Don't nub extra-libs in unionBuildInfo · d9233d60
      Duncan Coutts authored
      It's possible that we sometimes need to list the same library
      more than once if there are circular symbol references.
    • Duncan Coutts's avatar
      Fix unionBuildInfo · fd3d86e1
      Duncan Coutts authored
      Fix ticket #264 to use nub only on the fields which are treated as sets.
      Probably we should be using the right types and mappend for each field.
      Change to construct a new value from scratch rather than overriding one
      of the two args. This helps to make sure we're updating all the field
      as we get a warning if we miss any. Turns out we were missing the ghc
      profiling and shared libs options which meant they were getting dropped.
      That had the effect of ghc-prof-options: in .cabal files being ignored.
      Thanks to 'midfield' from #haskell for spotting this.
  6. 15 Apr, 2008 2 commits
  7. 13 Apr, 2008 6 commits
  8. 17 Apr, 2008 2 commits
  9. 12 Apr, 2008 1 commit
  10. 09 Apr, 2008 4 commits
    • Duncan Coutts's avatar
      Check for the required cabal version early in parsing · b6137f68
      Duncan Coutts authored
      Previously we only checked the "cabal-version" field after parsing
      and all other configure processing. If the package really needs a
      later Cabal version it is of course highly likely that parsing or
      configure are going to fail and the user is not going to get the
      helpful error message about the version of Cabal required. So now
      we do the check early during parsing. If a later version is
      required and parsing subsequently fails, we now report the version
      issue, not the subsequent parse error. If parsing succeeds we
      still issue a warning which should be a useful hint to the user if
      subsequent configure processing fails.
    • Duncan Coutts's avatar
      Use relative file paths in .cabal parse error messages · 8d931884
      Duncan Coutts authored
      Do this by normalising the file path in the error message
      and when looking for .cabal files, by looking in '.' rather
      than the absolute path of the current directory.
    • Duncan Coutts's avatar
      Remove unused import · 2fea05a5
      Duncan Coutts authored
    • Duncan Coutts's avatar
      Fix for detecting ~/.cabal/ dir as a .cabal file · ecf19959
      Duncan Coutts authored
      Which happened if you use cabal configure in your home dir.
      Now produced the right error message, or if you actually put
      a cabal project in your home dir, it might actually work.
      Also, do the same fix for findHookedPackageDesc.
  11. 08 Apr, 2008 1 commit
  12. 07 Apr, 2008 1 commit
    • Duncan Coutts's avatar
      Fix names of profiling libs · bd530c9f
      Duncan Coutts authored
      I broke this recently when refactoring. Restore the original behaviour.
      Was generating "libHSfoo_p-1.0.a" when it should be "libHSfoo-1.0_p.a".
  13. 29 Mar, 2008 1 commit
  14. 28 Mar, 2008 2 commits
  15. 27 Mar, 2008 8 commits
    • Duncan Coutts's avatar
      Simplify the parser for flags in conditions · 2ffbb5bf
      Duncan Coutts authored
      It's a bit more consistent.
    • Duncan Coutts's avatar
      We do not show the field value on a parse error so don't pretend we do. · 4f8a0220
      Duncan Coutts authored
      Drop the trailing ": " on the error message. We could provide the field
      value but they're often multi-line and we cannot pin-point where the
      error is exactly.
    • Duncan Coutts's avatar
      Use the Text Bool instance for parsing literals in conditions · 377d4365
      Duncan Coutts authored
      Since it exactly matches what the previous condition parser did.
      So we have two different ways of parsing Bool depending on
      context. Sigh. Both match exactly what was done in Cabal-1.2.
    • Duncan Coutts's avatar
      Parse Bool fields using more cunning, allow new parses with a warning · e92d6573
      Duncan Coutts authored
      We want to allow case-insensitive parsing however we don't want
      packages being uploaded to hackage that will break older versions of
      Cabal. If we allow new valid parses then we will end up breaking
      stuff. So what we really want to do is allow new parses but warn if
      they're not ones that older versions of Cabal would have allowed. So
      long as hackage rejects pakcages that have parse warnings then we can
      prevent new .cabal files appearing on hackage that would break older
      Cabal versions. Our current parser (ReadP) does not support warnings
      so we have to handle the bool fields specially in the parser wrapper
      layer that we added to handle errors and warnings. This can go away
      when we use a parser with support for error and warning messages.
    • Duncan Coutts's avatar
      Add scripts for testing compatability with hackage packages · 75867d1c
      Duncan Coutts authored
      So far just a test that all the non-trivial Setup.(l)hs scripts
      compile. This only tests the latest versions, though if one were
      to download a complete archive then one could test them all.
      To speed up the check we skip Setup.hs scripts that have fewer
      than 22 words. Below this cutoff there are no custom hooks and
      it catches the great majority of scripts which greatly speeds up
      the check.
    • Duncan Coutts's avatar
      Rename various *Verbose fields to *Verbosity instead · 556b9877
      Duncan Coutts authored
      Despite appearances this is actually not completely pointless.
      For the Cabal-1.4 branch we need the *Verbose fields to have the
      same types as they did in Cabal-1.2, becuase lots of Setup.hs
      scripts use them and our change to make them all have type Flag
      makes many Setup.hs scripts fail. A solution for the 1.4 branch
      is to rename the real field and to add the old field back in.
      To keep as much similarity as possible between the HEAD and 1.4
      branches I'm applying the name change in both.
      On the plus side it's a better name anyway.
    • Duncan Coutts's avatar
      Make UTF-8 decoding errors in .cabal files non-fatal · c4f0e7ca
      Duncan Coutts authored
      Previously we checked for invalid UTF-8 in the first phase of the
      parser, which splitting the file up into nested sections and fields.
      This meant the whole parser falls over if there is invalid UTF-8
      anywhere in the file. Sadly there are already packages on hackage
      with invalid UTF-8 so we would fail when parsing the hackage index.
      The solution is to move the check into the parsing of the individual
      fields and making it a warning not an error. We most typically get
      invalid UTF-8 in free text fields like author name, copyright,
      description etc so this should work out ok usually.
      We now get pretty decent error messages, like:
        Warning: hsx.cabal:5: Invalid UTF-8 text in the 'author' field.
      The warning type is now structured so that hackage will be able to
      distinguish general non-fatal warnings from UTF-8 decoding problems
      which really should be fatal errors for package uploads. 
    • Duncan Coutts's avatar
      Separate the OS/Arch classifiation used for different purposes · 507ed739
      Duncan Coutts authored
      We have to classify System.Info.{os,arch} strings into the OS and Arch
      enums. For that purpose we have to be quite permissive since there are
      lots of ailases that the various Haskell implementations use. However
      for parsing os and arch names in .cabal files we'd prefer to use
      canonical names, though we do have to allow the couple aliases already
      in common use.