This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 29 Mar, 2016 14 commits
    • Edward Z. Yang's avatar
      2d0b9afd
    • Edward Z. Yang's avatar
      Don't match dist-test directories. · 5d2697e4
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      5d2697e4
    • Edward Z. Yang's avatar
      90119466
    • Edward Z. Yang's avatar
      Remove redundant Tasty import. · 42177a43
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      42177a43
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Unconditionally turn on package name munging for components. · 516abff9
      Edward Z. Yang authored
      
      
      A lot of tooling (Cabal's included) assumes that if something in the
      installed package database has 'name: foo', it is a valid choice if
      we are dependency solving for 'foo'.
      
      If we always name internal libraries something else, this tooling
      will not get confused.  So let's help them out.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      516abff9
    • Edward Z. Yang's avatar
      Make register print the IPI when verbose (useful!) · 5239f89c
      Edward Z. Yang authored
      
      
      Also, unconditionally pass -v to cabal in package-tests.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      5239f89c
    • Edward Z. Yang's avatar
      Refactor ComponentLocalBuildInfo, fixing rpaths with internal libraries. · ca93c471
      Edward Z. Yang authored
      
      
      1. 'componentsConfigs' no longer is a graph identified by
          ComponentNames, but by ComponentIds (this is because, eventually,
          they'll be identified uniquely by a UnitId, but NOT by a
          ComponentName.) This caused some modest use-site changes but nothing
          major.
      
      2. To make it easier to get the Component given a ComponentLocalBuildInfo,
         I added a new field 'componentLocalName' which records the original
         source-level name of the 'ComponentLocalBuildInfo'.
      
      3. Rewrote the test in 'depLibraryPaths' which checks if a component
         is "internal" or not (arguably this should be factored into a common
         function, but at the moment it only occurs in one place.)
      
      4. Finally, 'depLibraryPaths' correctly takes the transitive closure
         of internal dependencies (rather than assuming that an internal
         dependency must be on the public library).
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      ca93c471
    • Edward Z. Yang's avatar
      Do not install/register internal libraries when unnecessary. · 86335745
      Edward Z. Yang authored
      
      
      This commit fails its tests, because dynamic executables
      linked against internal libraries aren't handled correctly
      yet.  I had to do more refactoring to handle this correctly,
      so it's in a separate commit.
      
      Some refactoring in this one for identifying public libraries
      as opposed to internal ones.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      86335745
    • Edward Z. Yang's avatar
      Per-component cabal_macros.h (#1893) and install paths · 90e908b8
      Edward Z. Yang authored
      
      
      This commit is a number of refactorings that I needed to do
      while fixing bugs with internal libraries support.
      
      - With internal libraries, it becomes especially clear that
        cabal_macros.h and Paths_foo.hs need to be done per-component.
        It is done!
      
        This change breaks BC in an important way: the preprocessor
        interface now takes a ComponentLocalBuildInfo along with the
        BuildInfo and LocalBuildInfo.  This means that if you implemented
        a custom preprocessor, or called 'preprocessComponent' in a custom
        Setup, you will have to make sure you pass the right
        ComponentLocalBuildInfo.  Some sub-notes:
      
          - While I was mucking about cabal_macros.h, I updated it to have
            two new macros: CURRENT_COMPONENT_ID (an alias for
            CURRENT_PACKAGE_KEY, but using modern terminology) and
            LOCAL_COMPONENT_ID (which refers to the public library; we use
            this in Cabal's test suite but it's unclear what the general
            utility of this is.  See the TODO.)
      
          - checkForeignDeps has a hack where we hardcode the
            cabal_macros.h of the main library.  If we did the foreign dep
            check for every component individually that would be better,
            but I didn't want to roll it into this patch.
      
      - The other piece I needed for internal libraries was per-component
        install directories; otherwise, internal libraries clobber each
        other.  absoluteInstallDirs now takes a ComponentId, which is used
        to determine what '$libname' expands to.  Generally, InstallPaths
        must be computed per component, c.f. #2836.  We're not TRULY
        per-component install paths, since some files are installed for
        the "per-package" InstallPaths (the one we computed for the
        library as a whole), but for libraries we have to compute
        InstallPaths for each one.
      
          - While doing this, ComponentLocalBuildInfo grew a new
            'componentId' field for non-library things.  This lets us
            treat InstallPaths expansion uniformly.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      90e908b8
    • Edward Z. Yang's avatar
      Implement "convenience libraries", fixes #269. · 2040c1c9
      Edward Z. Yang authored
      
      
      Convenience libraries are package-private libraries
      that can be used as part of executables, libraries, etc
      without being exposed to the external world.  Private
      libraries are signified using the
      
          library foo
      
      stanza.  Within a Cabal package, the name convenience library
      shadows the conventional meaning of package name in
      build-depends, so that references to "foo" do not indicate
      foo in Hackage, but the convenience library defined in the
      same package. (So, don't shadow Hackage packages!)
      
      This commit implements convenience libraries such that they
      ARE installed the package database (this prevents us from
      having to special case dynamically linked executables);
      in GHC 7.10 and later they are installed under the same
      package name as the package that contained them, but have
      a distinct "component ID" (one pay off of making the distinction
      between component IDs and installed package IDs.)
      
      There is a "default" library which is identified by the fact
      that its library name coincides with the package name.  There
      are some new convenience functions to permit referencing this.
      
      There are a few latent bugs in this commit which are fixed
      in later commits in this patchset.  (Those bugfixes required
      a bit of refactoring, so it's clearer if they're not
      with this patch.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      2040c1c9
    • Edward Z. Yang's avatar
      Add a custom setup to cabal-install. · 3c03ccce
      Edward Z. Yang authored
      
      
      This custom setup ensures that if we are bootstrapping, we will
      use the most recent version of Cabal.  (Without setup, cabal-install
      will force usage of an old version of Cabal.)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      3c03ccce
    • kristenk's avatar
      Merge pull request #3245 from grayjay/solver-quickcheck · 283f0af8
      kristenk authored
      Dependency solver quickcheck tests
      283f0af8
    • kristenk's avatar
      Start adding solver quickcheck tests · ce9e82cc
      kristenk authored
      ce9e82cc
  2. 27 Mar, 2016 10 commits
    • Mikhail Glushenkov's avatar
      Merge pull request #3244 from 23Skidoo/merge-1.24 · aa4d30d7
      Mikhail Glushenkov authored
      Merge nix-local-build changes from 1.24
      aa4d30d7
    • Mikhail Glushenkov's avatar
      80-col violations. · ebb6c552
      Mikhail Glushenkov authored
      ebb6c552
    • Mikhail Glushenkov's avatar
      Whitespace. · 2d68db11
      Mikhail Glushenkov authored
      2d68db11
    • Mikhail Glushenkov's avatar
      Update 'bootstrap.sh'. · 5c8c1c7c
      Mikhail Glushenkov authored
      5c8c1c7c
    • Duncan Coutts's avatar
      Quote package locations with spaces when printing · a4e54a68
      Duncan Coutts authored
      And extend the project config print/parse tests to cover quoted strings.
      
      (cherry picked from commit 72b93d91)
      a4e54a68
    • Duncan Coutts's avatar
      Extend file globs and file glob monitors · 2d569609
      Duncan Coutts authored
      File globs can now be absolute, e.g. starting with / or c:\
      Also allow homedir relative, ie ~/
      
      Globs can also have a trailing slash, in which case they only match
      directories, not files.
      
      Previously whether globs could match dirs was not totally consistent.
      The matchFileGlob would match dirs, but the file monitor globs would
      not. The file monitor globs can now match dirs (or with a trailing
      slash, only match dirs). File monitors now also detect changes in the
      file type, ie switching from file to dir or the other way around.
      
      The file monitor are now pretty consistent between single file monitors
      and globs monitors. They now have equivalent capabilities and share
      code. For a single file or for a glob we can now control what we
      monitor if the path is a file or a dir. In both cases we can monitor
      mere existence, non-existence or modification time. For files we can
      additionally monitor content hash.
      
      File monitors now also detect changes in the file type, ie switching
      from file to dir or the other way around.
      
      New tests cover all these new file monitor cases. There are also new
      tests for glob syntax, covering printing/parsing round trips.
      
      (cherry picked from commit f6c1e71c)
      2d569609
    • Duncan Coutts's avatar
      Add new style project building · a6526403
      Duncan Coutts authored
      This stage takes the ElaboratedInstallPlan and executes it. It does it
      in two passes.
      
      The first pass is the "dry run" pass where we work out which packages
      and components within packages we actually need to build. If we are in
      fact in --dry-run mode then of course this is the only pass we run, we
      have enough info after this to accurately report on what we would do.
      
      The first pass does the file monitor change stuff, which checks if
      package config has changed and probes for package file changes. Based on
      this we make a note of which phase of the build we would start at, up to
      and including skipping building that package entirely. In the latter
      case we replace the Configured package by a corresponding Installed
      package.
      
      The first pass also prunes the ElaboratedInstallPlan based on the
      targets that the user actually wants to build. For example we solve and
      plan on the basis that the user might want to run the test suites or
      benchmarks, but that doesn't mean we want to build them all the time
      (they'll usually pull in additional deps). So there's a moderately
      complex pass where we keep just the packages and components that are
      needed to build the target components.
      
      The first pass is moderately complicated but it makes no state changes
      and just returns the updated ElaboratedInstallPlan, so it should make
      things easier to debug.
      
      The second phase has very little logic it just does what its told based
      on all the earlier passes. For each package the dry run pass has worked
      out which build step to start with, e.g. downloading, configuring or
      building.
      
      The major cases the build phase has to deal with are packages that will
      be built and installed to the store, vs packages that are local and so
      are built inplace. It is only the latter that need all the complex
      rebuild checking. In both cases all the "setup $cmd" flags are
      calculated by the planning phase and we just do as we're told.
      
      (cherry picked from commit 300d9bad)
      a6526403
    • Duncan Coutts's avatar
      InstallPlan util to replace a ready package with an installed one · 3e13931e
      Duncan Coutts authored
      There are two cases in which we replace source packages with ones that
      are already installed: during planning when we improve the plan by
      replacing configured source packages with pre-existing packages from the
      store, but also there's just the case of skipping over a local package
      that is already built and up to date. In the latter case we're replacing
      a package in the Configured state not with one in the PreExisting state,
      but with one in the Installed state, as if it had been built and
      installed (which in a sense of course it has).
      
      This new util is for the latter case.
      
      (cherry picked from commit e869d803)
      3e13931e
    • Duncan Coutts's avatar
      Split out reusable lookupReadyPackage util in InstallPlan · 9d91e201
      Duncan Coutts authored
      Used in the next patch.
      
      (cherry picked from commit 150c3189)
      9d91e201
    • Duncan Coutts's avatar
      Add new style project planning · 352f5795
      Duncan Coutts authored
      This implements the planning phase of the new nix-style package build and
      install system. In particular it includes the calculation of the
      nix-style package ids by hashing all the package configuration.
      
      Project planning is separated from project building.
      
      The planning phase starts with finding the packages in the project and
      then solving. We solve without looking at the installed packages in the
      store. This makes everything more deterministic. The only installed
      packages the solver looks at are the globally installed ones. This
      approach also means we don't have any need of solver options like
      --reinstall or --avoid-reinstalls etc.
      
      The bulk of the planning phase is elaboration. We take the project
      configuration and the solver's InstallPlan and elaborate the latter into
      an ElaboratedInstallPlan. This is intended to contain all the details
      needed for the build phase. For example all the "setup" command flags
      are calculated directly from the elaborated plan.
      
      The building phase is then intended to be much simpler and free of much
      logic or policy. All of the complicated logic and policy is supposed to
      be in the planning phase. This should also make things a lot easier to
      debug, we can look at the plan we calculate and see if we're producing
      the right build instructions, rather than debugging based on the actions
      we end up executing.
      
      Doing all the planning up front is also crucial to calculating nix-style
      package hashes. This means we have the package ids up front. This then
      allows us to have another up-front phase where we improve the plan by
      replacing source packages with installed packages from the store.
      
      All of this stuff is done in the Rebuild monad, with a few levels of
      caches, so most of the time we can avoid recomputing the plan. In
      particular we want to avoid re-running the solver unless we have to.
      
      There are still quite a number of TODOs, which are categorised.
      
      (cherry picked from commit 2d065c8c)
      352f5795
  3. 21 Mar, 2016 2 commits
  4. 20 Mar, 2016 2 commits
  5. 19 Mar, 2016 3 commits
  6. 18 Mar, 2016 1 commit
  7. 17 Mar, 2016 8 commits