1. 13 Nov, 2014 2 commits
    • Niklas Hambuechen's avatar
      Use Cabal to enforce dependency versions · 8e193466
      Niklas Hambuechen authored
      This uses `cabal configure` to determine which exact dependency versions
      we are compiling against, and ensures that these versions are used
      by passing -package-id flags to GHC.
      
      The `cabal configure` step makes the build fail before compiling / type
      checking if the user tries to compile against a dependency version we don't
      support; before, this case led to type errors which were not clearly
      user errors. This fixes issue #988.
      
      The output of `cabal configure` is also used to generate MIN_VERSION_*
      macros.
      
      MIN_VERSION_* macros are the standard way to build CPP dependency switches
      in Haskell packages, and they replace our custom macros (like PARALLEL3
      and NO_REGEX_PCRE) which had to be hand-built for each dependency.
      We can now query the version of any Haskell dependency without having
      to manually add a flag via autoconf.
      
      All ghc and hlint invocations were adjusted to take these macros into
      account.
      
      This change introduces a Haskell-build-time dependency on cabal-install
      (for `cabal configure`) and the Cabal API (for obtaining the configured
      dependency versions and generating the macros).
      Any cabal version since Debian Squeeze is supported.
      
      Note that our use of Cabal does not imply any downloading of dependencies
      at build time, hermetic builds are unaffected by this change.
      
      For developers we now require hlint >= 1.8.60, to make use of its
      --cpp-file option.
      However, hlint >= 1.9.12 is recommended since for
      hlint >= 1.8.58 && < 1.9.12 the --utf8 flag is non-functional
      (see https://github.com/ndmitchell/hlint/issues/96); this can be worked
      though by using the equivalent `--encoding=UTF-8` flag.
      Signed-off-by: default avatarNiklas Hambuechen <niklash@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
      8e193466
    • Niklas Hambuechen's avatar
      Add cabal file generation to Makefile.am · 3736b078
      Niklas Hambuechen authored
      This allows us to specify the exact version ranges of dependencies we
      support, across all operating systems.
      
      See issue #988.
      
      This commit only adds the cabal file and declares the dependencies.
      Enforcing them will be subject of a later commit.
      
      So far, we have only given the names of dependency in most cases,
      making sure that Ganeti builds with the dependency versions that are in
      Debian.
      This has caused problems for users that were not running Debian, or
      when there were packages installed in the compiling user's ~/.ghc
      directory, leading to compile-time type errors instead of pre-build
      configuration errors; for an example, see:
        https://code.google.com/p/ganeti/issues/detail?id=979#c10
      
      By explicitly listing our dependencies, we make clear which versions
      are supported.
      
      Modules and executables listed in the cabal file are automatically
      generated from the Makefile; executables are symlinked in an apps/
      directory to avoid repeated compilation as explained in:
      
        http://stackoverflow.com/a/6711739/263061
        http://stackoverflow.com/q/12305970/263061
      
      For example, in apps/ there is:
      
        hluxid.hs -> ../src/hluxid.hs
        hluxid.hs.stamp
        [...]
      
      Each executable symlink has a stamp file to track its modification time
      because make follow symlinks and thus does not see symlink modification
      times.
      
      In addition to declaring our dependencies, this setup allows building
      Ganeti's Haskell code with cabal to support editor integration and
      cabal-based tooling, the Makefile remains the default way to build Ganeti.
      Signed-off-by: default avatarNiklas Hambuechen <niklash@google.com>
      Reviewed-by: default avatarKlaus Aehlig <aehlig@google.com>
      3736b078
  2. 12 Nov, 2014 1 commit
  3. 11 Nov, 2014 1 commit
  4. 10 Nov, 2014 1 commit
  5. 07 Nov, 2014 1 commit
  6. 05 Nov, 2014 2 commits
  7. 04 Nov, 2014 3 commits
  8. 03 Nov, 2014 4 commits
  9. 31 Oct, 2014 1 commit
  10. 30 Oct, 2014 1 commit
  11. 24 Oct, 2014 1 commit
  12. 22 Oct, 2014 2 commits
  13. 21 Oct, 2014 1 commit
  14. 20 Oct, 2014 3 commits
  15. 15 Oct, 2014 2 commits
  16. 10 Oct, 2014 1 commit
  17. 08 Oct, 2014 2 commits
  18. 07 Oct, 2014 4 commits
  19. 02 Oct, 2014 1 commit
    • Helga Velroyen's avatar
      Introducing the 'ssh_update' tool · 2be56731
      Helga Velroyen authored
      In order to update the 'ganeti_pub_keys' and the
      'authorized_keys' files of various nodes via SSH, we
      introduce the tool 'ssh_update'. It works similar to the
      tool 'prepare_node_join', which is also a tool invoked
      via SSH on a remote note.
      
      This patch includes some refactoring to reuse code from
      the 'prepare_node_join' tool and provides unit tests as
      well. Note that the actual invocation of the 'ssh_update'
      tool will be done in later patches of this series.
      Signed-off-by: default avatarHelga Velroyen <helgav@google.com>
      Reviewed-by: default avatarPetr Pudlak <pudlak@google.com>
      2be56731
  20. 30 Sep, 2014 2 commits
  21. 29 Sep, 2014 4 commits