This project is mirrored from Pull mirroring updated .
  1. 14 May, 2007 1 commit
    • Ian Lynagh's avatar
      Make a proper verbosity type, rather than using Int values · 28847431
      Ian Lynagh authored
      Hopefully this will make it easier to get better verbosity consistency.
      We could, by changing only Distribution.Verbosity, use
      "type Verbosity = Int" for now to give users of the library a chance to
      catch up, but the upcoming Cabal release seems like a good opportunity
      to cram in as much of the interface-changing stuff that we want to do
      as we can. I think the added benefit of a slow switch would be very low
  2. 13 May, 2007 2 commits
  3. 01 May, 2007 1 commit
  4. 04 May, 2007 1 commit
  5. 03 May, 2007 5 commits
  6. 02 May, 2007 4 commits
  7. 01 May, 2007 5 commits
  8. 22 Apr, 2007 3 commits
    •'s avatar
      call c2hs using the more detailed info · d1ce7140 authored
      we use --output-dir=dist/base
      and --output=<file relative to the search dir it was found in>.hs
      This actually depends on a patch in c2hs to make it treat --output-dir
      in the way we want. That patch will be forthcomming soonish.
      But the point is:
      c2hs --output-dir=dist/base --output=Foo/Bar.hs src/Foo/Bar.chs
      will generate dist/base/Foo/Bar.hs and also dist/base/Foo/Bar.h
      but inside the .hs file it'll reference Foo/Bar.h so when we compile the
      .hs file we have to -Idist/base
      Clear as mud?
    •'s avatar
      Generalise PreProcessors to take more detailed args · f55dda73 authored
      Most pre-processors just need the full source file and target file names.
      More complicated ones where the generated files have to embed links to each
      other need more information. For example c2hs generates .hs file that
      reference generated .h files. These links should be relative to the dist/build
      dir and not to the top of the source tree, since we do not want to add -I. to
      the includes search path. We only want to use -Idist/build, hence the embeded
      links must be relative to that. Therefor c2hs needs to know the base output
      directory as well as the name of the file relative to that.
      So we add a new type PreProcessorFull that has this extra info and a function
      simplePP :: :: PreProcessor -> PreProcessorFull
      for the common case of most existing pre-processors that do not need this
      extra info.
      This patch doesn't actually change the c2hs stuff, that comes next.
    •'s avatar
      Put pre-processed source into the dist/build dir rather than src dirs · 1007707d authored
      This is generally just a nicer thing to do, we should probably aim to
      not write any files into the source tree at all.
      The main change is in the preprocessModule function. It now takes an extra
      arg which is the destination directory. For now I'm passing the buildDir,
      but we could consider putting pre-processed files into a separate fir
      from where the .o and .hi files end up.
      To work out the correct destination file we need to know not only the source
      file but which of the search dirs it was found in, since the relative file
      name will be the name of the source file relative to the search dir it was
      found in, not the name relative to the top of the source tree. This is so that
      we will be able to find the pre-processed .hs file just by adding dist/build
      to the sources search path when we compile (eg with -i for ghc).
      This almost certainly breaks the sdist thing where pre-processed files get
      included into the tarball. So that'll need looking at.
  9. 20 Apr, 2007 3 commits
  10. 30 Apr, 2007 4 commits
    •'s avatar
      Don't overwrite existing makefiles · 02eda632 authored
      Patch contributed by Bryan O'Sullivan
    •'s avatar
      Fix openTempFile so it works on windows with ghc at least · 5390172f authored
      It's still a hack. The right solution is to proerly implement openTempFile
      in base for all Haskell impls, not just GHC.
    •'s avatar
      Use rawSystem not system for capturing output of commands · 1cbfb5e0 authored
      For example we were using a wrapper around 'system' to find the haddock
      version. This invokes the system command interpreter and passes the
      command to run as an argument. If the command has spaces in it and is not
      properly escaped then everything goes wrong. This happens for example
      on windows when haddock and other programs are kept under "Program Files".
      So the right thing to do is never to use system, but always rawSystem since
      then there are no escaping issues.
      This patch replaces a couple function systemCaptureStdout and systemGetStdout
      with rawSystemStdout which now lives in Distribution.Simple.Utils.
      This also uses some rather nasty code to get the output of a command.
      It really really should not be this hard to do portably. To work around
      the fact that we cannot use runInteractiveProcess we instead have to create
      a temporary file. This also turns out to be a hack because the 'standard'
      openTempFile is not implemented except by GHC, so we now have a hacky version
      living in Distribution.Compat.TempFile just waiting for the standard 
      openTempFile to be made properly portable, or for us to get some
      System.Process function that does what we want.
    •'s avatar
      Fix the verbosity level for printing executed commands · c514358c authored
      Since 1 is the default verbosity level we should only print commands
      at level 2 and above.
  11. 24 Apr, 2007 2 commits
  12. 12 Feb, 2007 1 commit
  13. 23 Apr, 2007 1 commit
  14. 19 Apr, 2007 1 commit
  15. 18 Apr, 2007 5 commits
  16. 17 Apr, 2007 1 commit