This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 13 Apr, 2008 5 commits
  2. 17 Apr, 2008 2 commits
  3. 12 Apr, 2008 1 commit
  4. 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.
      b6137f68
    • 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.
      8d931884
    • Duncan Coutts's avatar
      Remove unused import · 2fea05a5
      Duncan Coutts authored
      2fea05a5
    • 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.
      ecf19959
  5. 08 Apr, 2008 1 commit
  6. 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".
      bd530c9f
  7. 29 Mar, 2008 1 commit
  8. 28 Mar, 2008 2 commits
  9. 27 Mar, 2008 9 commits
    • Duncan Coutts's avatar
      Simplify the parser for flags in conditions · 2ffbb5bf
      Duncan Coutts authored
      It's a bit more consistent.
      2ffbb5bf
    • 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.
      4f8a0220
    • 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.
      377d4365
    • 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.
      e92d6573
    • 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.
      75867d1c
    • 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.
      556b9877
    • 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. 
      c4f0e7ca
    • 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.
      507ed739
    • Duncan Coutts's avatar
      Arch and OS names were previously allowed to contain "_-", restore that. · 0f45e192
      Duncan Coutts authored
      That is the arch and os strings in conditionals in .cabal files, like:
        if arch(x86_64)
      Previously the parser used isAlphaNum c || (c `elem` "_-"). This is
      crucial for arch names like "x86_64". So make the new parser for OS
      and Arch types use the same string parser as before (there is a string
      parse part and a separate classification of known OS/Arch values).
      0f45e192
  10. 26 Mar, 2008 5 commits
  11. 25 Mar, 2008 9 commits