This project is mirrored from Pull mirroring updated .
  1. 29 Mar, 2016 24 commits
  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
    • Mikhail Glushenkov's avatar
      80-col violations. · ebb6c552
      Mikhail Glushenkov authored
    • Mikhail Glushenkov's avatar
      Whitespace. · 2d68db11
      Mikhail Glushenkov authored
    • Mikhail Glushenkov's avatar
      Update ''. · 5c8c1c7c
      Mikhail Glushenkov authored
    • 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)
    • 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)
    • 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
      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
      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)
    • 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)
    • 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)
    • 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)
  3. 21 Mar, 2016 2 commits
  4. 20 Mar, 2016 2 commits
  5. 19 Mar, 2016 2 commits