1. 31 Mar, 2015 1 commit
  2. 15 Mar, 2015 1 commit
  3. 08 Mar, 2015 1 commit
  4. 28 Feb, 2015 1 commit
  5. 26 Feb, 2015 1 commit
  6. 24 Feb, 2015 2 commits
  7. 17 Feb, 2015 1 commit
  8. 18 Dec, 2014 1 commit
    • Ross Smith's avatar
      Detect and propagate _FORTIFY_SOURCE prefix · 1c3d093c
      Ross Smith authored
      Get prefix to a -D_FORTIFY_SOURCE string if it is present in
      CFLAGS and apply the prefix to flags added to redefine
      _FORTIFY_SOURCE in CFLAGS and CPPFLAGS
      
      * fixes 1569
      1c3d093c
  9. 16 Dec, 2014 2 commits
    • John Szakmeister's avatar
      build: include the flags for the build type in the _FORTIFY_SOURCE check · 0a5dad8a
      John Szakmeister authored
      It turns out the check was being performed without optimizations enabled
      even when the CMAKE_BUILD_TYPE was set to a release build.  This led to
      _FORTIFY_SOURCE's level not being correctly determined, and us failing
      to apply the correct workaround.
      
      To counter this, we'll take the default flags for the build type and
      apply them.  Also, if options are passed via CFLAGS, they are
      automatically passed on to the underlying build.  So this should cover
      all the necessary ground.
      
      This fixes #1647.
      0a5dad8a
    • Rui Abreu Ferreira's avatar
      Allow cmake caller to override DEPS_PREFIX · 8d54a720
      Rui Abreu Ferreira authored
      - Caller can override bundled dependency location using
        DEPS_PREFIX
      - Cache variable DEPS_PREFIX, using .deps/usr by default
      - Removed unused variables DEPS_BIN_DIR, DEPS_BUILD_DIR, DEPS_DIR
        DEPS_INSTALL_DIR
      - Corner case: if the caller tries to override DEPS_PREFIX after a
        successful cmake configuration, the caller needs to clear the cache
        because dependency checks are based on the old value
      8d54a720
  10. 12 Dec, 2014 1 commit
  11. 26 Nov, 2014 1 commit
  12. 19 Nov, 2014 1 commit
  13. 14 Nov, 2014 1 commit
    • Rui Abreu Ferreira's avatar
      Use cmake --build instead of Make · 2b887ec6
      Rui Abreu Ferreira authored
      - If possble try to abstract away from Make, and use cmake --build
      - third-party still needs to find Make to build some components
      - Removed search for Make from CMakeLists.txt
      * for CMake < 3.0 --build has no color output
      2b887ec6
  14. 11 Nov, 2014 1 commit
    • John Szakmeister's avatar
      build: fix CMAKE_MODULE_PATH usage · 25401555
      John Szakmeister authored
      Fixes #1447.  `CMAKE_MODULE_PATH` is meant to be a list of directories,
      and as such, is not the proper way to launch our scripts.  Let's use
      `${PROJECT_SOURCE_DIR}/cmake` instead.  Also, let's not outright set
      `CMAKE_MODULE_PATH`, but instead append our location to the list.
      25401555
  15. 09 Nov, 2014 2 commits
  16. 08 Nov, 2014 4 commits
    • John Szakmeister's avatar
      build: pull iconv detection into its own FindIconv.cmake file · 9344a40e
      John Szakmeister authored
      This will provide better control for those who may want to alter which
      one gets used.
      9344a40e
    • John Szakmeister's avatar
      build: give priority to /sw and /opt/local on Mac OS X · 203a5166
      John Szakmeister authored
      Unfortunately, we can't force the specific inclusion of a header file.
      So if anything add /opt/local/include to the include path--such as
      libintl--then other dependencies might be drawn from /opt/local at
      compile time, even though we detected them elsewhere at configure time.
      This, in turn, causes issues with mixed versions, such as the iconv.h
      header being pulled from /opt/local/include, but linked against the
      library in /usr/lib--which can be mismatched versions.
      
      So, despite CMake's best effort to treat /sw and /opt/local as just
      another system area, we really need to give them preferential treatment.
      To do this, we add them to CMAKE_PREFIX_PATH.
      
      This fixes an issue discovered while re-enabling iconv in #1370.
      203a5166
    • John Szakmeister's avatar
      build: use the proper libintl include variable · 05f78d30
      John Szakmeister authored
      What was there worked, but it wasn't meant to be the variable that you
      use for inclusion.
      05f78d30
    • Florian Walch's avatar
      a1d411f9
  17. 07 Nov, 2014 1 commit
  18. 05 Nov, 2014 4 commits
  19. 17 Oct, 2014 1 commit
  20. 16 Oct, 2014 1 commit
    • Thiago de Arruda's avatar
      test: Remove run-functional-tests.py · 69561ea9
      Thiago de Arruda authored
      Now that the lua client is available, python/lupa are no longer necessary to run
      the functional tests. The helper functions previously defined in
      run-functional-tests.py were adapted to test/functional/helpers.lua.
      69561ea9
  21. 15 Oct, 2014 1 commit
  22. 07 Oct, 2014 2 commits
  23. 30 Sep, 2014 1 commit
    • Thiago de Arruda's avatar
      test: Replace vroom by lua/busted for functional tests · 42d5b526
      Thiago de Arruda authored
      The 'lupa' python package provides a simple way to seamless integrate lua and
      python code.
      
      This commit replaces vroom by a python script that exposes the 'neovim' package
      to a lua state, and invokes busted to run functional tests. This is a temporary
      solution that will enable writing functional tests using lua/bused while a lua
      client library is not available.
      
      The reason for dropping vroom is flexibility: Lua/busted has a nice DSL-style
      syntax while also providing the customization power of a full programming
      language. Another reason is to use a single framework for unit/functional tests.
      
      Two other changes were performed in this commit:
      
      - Instead of "gcc-unittest/gcc-ia32", the travis builds for gcc are now
        identified by "gcc/gcc-32". They will run unit/functional tests for both 64
        and 32 bits.
      - Old integration tests(in src/nvim/testdir) are now ran by the 'oldtest' target
      42d5b526
  24. 22 Sep, 2014 1 commit
    • John Szakmeister's avatar
      build: install with the correct permissions · 0d353693
      John Szakmeister authored
      The install() command will create the parent directories, but it does so
      with the user's umask.  We want to do our best to make sure the correct
      permissions are being set, without clobbering existing permissions.
      
      To do this, this commit introduces an install_helper(), which is similar
      in signature to the install() command, to help ensure that directories
      are created ahead of the actual install() command.  This will attempt to
      use 0644 permissions for files and 0755 permissions for directories by
      default--though they can be overridden.
      
      To make this work correctly, without trying to introduce some mechanism
      with setting the umask, it meant that there's a small portion that makes
      use of an "internal" version of the file() command.  It has been tested
      on CMake 2.8.11, 2.8.12, and 3.0.2, and works correctly on all versions.
      
      This fixes #1201 and #1086.
      0d353693
  25. 16 Sep, 2014 1 commit
  26. 11 Sep, 2014 1 commit
  27. 29 Aug, 2014 1 commit
  28. 23 Aug, 2014 2 commits
  29. 31 Jul, 2014 1 commit