1. 11 Nov, 2017 1 commit
    • cmake: Allow user to select bundled zlib · a0b0b808
      Under some circumstances the installed / system version of zlib may not
      be desirable due to being too old or buggy.  This patch adds the option
      `USE_BUNDLED_ZLIB` that will cause the bundled version of zlib to be
      used.
      
      We may also want to add similar functionality to allow the user to
      select other bundled 3rd-party dependencies instead of using the system
      versions.
      
      /cc @pks-t @ethomson
      Henry Kleynhans committed
  2. 23 Oct, 2017 4 commits
  3. 20 Oct, 2017 1 commit
    • cmake: use project-relative binary and source directories · 4da74c83
      Due to our split of CMake files into multiple modules, we had to replace
      some uses of the `${CMAKE_CURRENT_SOURCE_DIR}` and
      `${CMAKE_CURRENT_BINARY_DIR}` variables and replace them with
      `${CMAKE_SOURCE_DIR}` and `${CMAKE_BINARY_DIR}`. This enabled us to
      still be able to refer to top-level files when defining build
      instructions inside of a subdirectory.
      
      When replacing all variables, it was assumed that the absolute set of
      variables is always relative to the current project. But in fact, this
      is not the case, as these variables always point to the source and
      binary directory as given by the top-levl project. So the change
      actually broke the ability to include libgit2 directly as a subproject,
      as source files cannot be found anymore.
      
      Fix this by instead using project-specific source and binary directories
      with `${libgit2_SOURCE_DIR}` and `${libgit2_BINARY_DIR}`.
      Patrick Steinhardt committed
  4. 14 Oct, 2017 1 commit
  5. 22 Sep, 2017 1 commit
    • cmake: use static dependencies when building static libgit2 · 49551254
      CMake allows us to build a static library by simply setting the variable
      `BUILD_SHARED_LIBS` to `OFF`. While this causes us to create a static
      libgit2.a archive, it will not automatically cause CMake to only locate
      static archives when searching for dependencies. This does no harm in
      case of building our libgit2.a, as we do not want to include all
      required dependencies in the resulting archive anyway. Instead, we ask
      users of a static libgit2.a to link against the required set of static
      archives themselves, typically aided by the libgit2.pc file.
      
      Where it does cause harm, though, is when we build the libgit2_clar test
      suite. CMake has happily populated our LIBGIT2_LIBS variable with shared
      libraries, and so linking the final libgit2_clar test does not do the
      right thing. It will simply ignore those shared libraries, we end up
      with a test suite with undefined symbols.
      
      To fix the issue, we can instruct CMake to only locate libraries with a
      certain suffix. As static libraries are typically identifiable by their
      ".a" suffix on Unix-based systems, we can instruct CMake to only locate
      libraries with this suffix to restrict it from finding any shared
      libraries. This fixes building a static libgit2_clar test suite.
      
      Note that this ignores the problem on Windows. The problem here is that
      we cannot even distinguish static and dynamic libraries by only
      inspecting their suffix. So we just ignore the problem on Windows, for
      now.
      Patrick Steinhardt committed
  6. 20 Sep, 2017 1 commit
    • cmake: bump minimum version to 2.8.11 · cf9f3452
      Our current minimum CMake version is 2.8. This version does not yet
      allow us to use object libraries (introduced in 2.8.8) and target
      include directories (introduced in 2.8.12), which are both mechanisms we
      want to use to fix some specific problems. We previously were not able
      to bump our CMake version to a version supporting object libraries
      because Ubuntu Precise only had CMake version 2.8.7 in its repositories.
      But due to Precise being end of life now, we shouldn't need to honor it
      anymore. A current survey of some of the more conservative distributions
      brings up the following versions of CMake:
      
      - CentOS 5: 2.6.2
      - CentOS 6: 2.8.12.2
      - Debian 7: 2.8.11
      - Fedora 23: 3.3.2
      - OpenSUSE 13.2: 3.0.2
      - Ubuntu Precise: 2.8.7
      - Ubuntu Trusty: 2.8.12
      
      The only two outliers here are CentOS 5 and Ubuntu Precise. CentOS is
      currently unsupported due to our minimum version being 2.8 and Ubuntu
      Precise is not maintained anymore. So the next smallest version
      supported by all major distributions is 2.8.11. While this does not yet
      support target include directories, it at least enables us to use object
      libraries. So this becomes our new minimum required version.
      Patrick Steinhardt committed
  7. 15 Sep, 2017 2 commits
    • cmake: fix linker error with dbghelper library · 54214d61
      When the MSVC_CRTDBG option is set by the developer, we will link in the
      dbghelper library to enable memory lead detection in MSVC projects. We
      are doing so by adding it to the variable `CMAKE_C_STANDARD_LIBRARIES`,
      so that it is linked for every library and executable built by CMake.
      But this causes our builds to fail with a linker error:
      
      ```
          LINK: fatal error LNK1104: cannot open file 'advapi32.lib;Dbghelp.lib'
      ```
      
      The issue here is that we are treating the variable as if it were an
      array of libraries by setting it via the following command:
      
      ```
          SET(CMAKE_C_STANDARD_LIBRARIES "${CMAKE_C_STANDARD_LIBRARIES}"
              "Dbghelp.lib")
      ```
      
      The generated build commands will then simply stringify the variable,
      concatenating all the contained libraries with a ";". This causes the
      observed linking failure.
      
      To fix the issue, we should just treat the variabable as a simple
      string. So instead of adding multiple members, we just add the
      "Dbghelp.lib" library to the existing string, separated by a space
      character.
      Patrick Steinhardt committed
    • cmake: enable reproducible static linking · d630887b
      By default, both ar(1) and ranlib(1) will insert additional information
      like timestamps into generated static archives and indices. As a
      consequence, generated static archives are not deterministic when
      created with default parameters.
      
      Both programs do support a deterministic mode, which will simply zero
      out undeterministic information with `ar D` and `ranlib -D`.
      Unfortunately, CMake does not provide an easy knob to add these command
      line parameters. Instead, we have to redefine the complete command
      definitons stored in the variables CMAKE_C_ARCHIVE_CREATE,
      CMAKE_C_ARCHIVE_APPEND and CMAKE_C_ARCHIVE_FINISH.
      
      Introduce a new build option `ENABLE_REPRODUCIBLE_BUILDS`. This option
      is available on Unix-like systems with the exception of macOS, which
      does not have support for the required flags. If the option is being
      enabled, we add those flags to the invocation of both `ar` and `ranlib`
      to enable deterministically building the static archive.
      Patrick Steinhardt committed
  8. 25 Aug, 2017 2 commits
    • cmake: add switch to build with -Werror · 175ab8e7
      Add a simple switch to enable building with "-Werror=<warning>" instead
      of "-W<warning". Due to the encapsulated `ENABLE_WARNINGS` macro, this
      is as simple as adding a new variable "ENABLE_WERROR`, which can be
      passed on the command line via `-DENABLE_WERROR=ON`. The variable
      defaults to NO to not bother developers in their day to day work.
      Patrick Steinhardt committed
    • cmake: encapsulate enabling/disabling compiler warnings · 4a46a8c1
      There are multiple sites where we enable or disable compiler warning via
      "-W<warning>" or "-Wno-<warning>". As we want to extend this mechanism
      later on to conditionally switch these over to "-Werror=<warning>", we
      encapsulate the logic into its their own macros `ENABLE_WARNINGS` and
      `DISABLE_WARNINGS`.
      
      Note that we in fact have to use a macro here. Using a function would
      not modify the CFLAGS inside of the callers scope, but in the function's
      scope only.
      Patrick Steinhardt committed
  9. 16 Aug, 2017 19 commits
    • cmake: move library build instructions into subdirectory · e5c9723d
      To fix leaking build instructions into different targets and to make
      the build instructions easier to handle, create a new CMakeLists.txt
      file containing build instructions for the libgit2 target.
      
      By now, the split is rather easy to achieve. Due to the preparatory
      steps, we can now simply move over all related build instructions, only
      needing to remove the "src/" prefix from some files.
      Patrick Steinhardt committed
    • cmake: fix up source and binary directory paths · 72f27cb6
      There are quite some uses of the variables "${CMAKE_CURRENT_SOURCE_DIR}"
      and "${CMAKE_CURRENT_BINARY_DIR}" where they are not appropriate.
      Convert these sites to instead use the variables "${CMAKE_SOURCE_DIR}"
      and "${CMAKE_BINARY_DIR}", which instead point to the project's root
      directory.
      
      This will ease splitting up the library build instructions into its own
      subdirectory.
      Patrick Steinhardt committed
    • cmake: move zlib build instructions into subdirectory · 1f43a43d
      Extract code required to build the zlib library into its own
      CMakeLists.txt, which is included as required.
      Patrick Steinhardt committed
    • cmake: move http-parser build instructions into subdirectory · b7514554
      Extract code required to build the http-parser library into its own
      CMakeLists.txt, which is included as required.
      Patrick Steinhardt committed
    • cmake: move regex build instructions into subdirectory · 9e449e52
      Extract code required to build the regex library into its own
      CMakeLists.txt, which is included as required.
      Patrick Steinhardt committed
    • cmake: move winhttp build instructions into subdirectory · 43248500
      Extract code required to build the winhttp library into its own
      CMakeLists.txt, which is included as required.
      Patrick Steinhardt committed
    • cmake: define WIN_RC with other platform sources · bed7ca3a
      This makes splitting up the library build instructions later on more
      obvious and easier to achieve.
      Patrick Steinhardt committed
    • cmake: find dependencies after setting build flags · 8ee90c39
      This makes splitting up the library build instructions later on more
      obvious and easier to achieve.
      Patrick Steinhardt committed
    • cmake: move definition of Win32 flags together · c3635130
      This makes splitting up the library build instructions later on more
      obvious and easier to achieve.
      Patrick Steinhardt committed
    • cmake: inline TARGET_OS_LIBRARIES function · 32a2e500
      Previous to keeping track of libraries and linking directories via
      variables, we had two call sites of the `TARGET_OS_LIBRARIES` function
      to avoid duplicating knowledge on required operating system library
      dependencies. But as the libgit2_clar target now re-uses defined
      variables to link against these libraries, we can simply inline the
      function.
      Patrick Steinhardt committed
    • cmake: keep track of libraries and includes via lists · 8e31cc25
      Later on, we will move detection of required libraries, library
      directories as well as include directories into a separate
      CMakeLists.txt file inside of the source directory. Obviously, we want
      to avoid duplication here regarding these parameters.
      
      To prepare for the split, put the parameters into three variables
      LIBGIT2_LIBS, LIBGIT2_LIBDIRS and LIBGIT2_INCLUDES, tracking the
      required libraries, linking directory as well as include directories.
      These variables can later be exported into the parent scope from inside
      of the source build instructions, making them readily available for the
      other subdirectories.
      Patrick Steinhardt committed
    • cmake: use absolute path to deps · dd332e2a
      When refering to files and directories inside of the top-level "deps/"
      directory, we're being inconsistent in using relative or absolute paths.
      To enable splitting out parts of the top-level CMakeLists.txt into an
      own file in the "src/" directory, consistently switch over to use
      absolute paths to avoid errors when converting.
      Patrick Steinhardt committed
    • cmake: move regcomp and futimens checks to "features.h" · 8341d6cf
      In our CMakeLists.txt, we have to check multiple functions in order to
      determine if we have to use our own or whether we can use the
      platform-provided one. For two of these functions, namely `regcomp_l()`
      and `futimens`, the defined macro is actually used inside of the header
      file "src/unix/posix.h". As such, these macros are not only required by
      the library, but also by our test suite, which is makes use of internal
      headers.
      
      To prepare for the CMakeLists.txt split, move these two defines inside
      of the "features.h" header.
      Patrick Steinhardt committed
    • cmake: move defines into "features.h" header · a390a846
      In a future commit, we will split out the build instructions for our
      library directory and move them into a subdirectory. One of the benefits
      is fixing scoping issues, where e.g. defines do not leak to build
      targets where they do not belong to. But unfortunately, this does also
      pose the problem of how to propagate some defines which are required by
      both the library and the test suite.
      
      One way would be to create another variable keeping track of all added
      defines and declare it inside of the parent scope. While this is the
      most obvious and simplest way of going ahead, it is kind of unfortunate.
      The main reason to not use this is that these defines become implicit
      dependencies between the build targets. By simply observing a define
      inside of the CMakeLists.txt file, one cannot reason whether this define
      is only required by the current target or whether it is required by
      different targets, as well.
      
      Another approach would be to use an internal header file keeping track
      of all defines shared between targets. While configuring the library, we
      will set various variables and let CMake configure the file, adding or
      removing defines based on what has been configured. Like this, one can
      easily keep track of the current environment by simply inspecting the
      header file. Furthermore, these dependencies are becoming clear inside
      the CMakeLists.txt, as instead of simply adding a define, we now call
      e.g. `SET(GIT_THREADSAFE 1)`.
      
      Having this header file though requires us to make sure it is always
      included before any "#ifdef"-preprocessor checks are executed. As we
      have already refactored code to always include the "common.h" header
      file before any statement inside of a file, this becomes easy: just make
      sure "common.h" includes the new "features.h" header file first.
      Patrick Steinhardt committed
    • cmake: create separate CMakeLists.txt for tests · 35087f0e
      Our CMakeLists.txt is very unwieldy in its current size, spanning more
      than 700 lines of code. Furthermore, it has several issues regarding
      scoping, where for example some defines, includes, etc. from our test
      suite are also applied to our normal library code.
      
      To fix this, we can separate out build instructions for our tests and
      move them into their own CMakeLists.txt in the "tests" directory. This
      reduced complexity of the root CMakeLists.txt file and fixes the issues
      regarding leaking build context from tests into the library.
      Patrick Steinhardt committed
    • cmake: create own precompiled headers for tests · 3267115f
      As soon as we split up our CMakeBuild.txt build instructions, we will be
      unable to simply link against the git2 library's precompiled header from
      other targets. To avoid this future breakage, create a new precompiled
      header for our test suite. Next to being compatible with the split, this
      enables us to also include additional files like the clar headers, which
      may help speeding up compilation of the test suite.
      Patrick Steinhardt committed
    • cmake: create object library target · caab8270
      Currently, we're compiling our library code twice, once as part of the
      libgit2 library and once for the libgit2_clar executable. Since CMake
      2.8.8, there exists a new library type OBJECT, which represents an
      intermediate target which can then subsequently be used when linking
      several targets against the same set of objects.
      
      Use an OBJECT library to create an internal library for linking. This
      new target is only used on CMake v2.8.8 or newer. As CMake 3.0 changed
      the way how generator expressions are evaluated when accessing
      properties, we need to enable CMake policy 0051 to keep
      `IDE_SPLIT_SOURCES` functioning.
      Patrick Steinhardt committed
    • cmake: remove unused variable "CLAR_RESOURCES" · f33911e5
      Once upon a time, the `CLAR_RESOURCES` variable was intended to set
      the `CLAR_RESOURCES` define. But actually, the define uses a wrong
      variable name by accident, hinting that its value cannot actually be
      used at all, as it is empty. Searching through the code base confirms
      the guess that the define is not used at all.
      
      Remove both the variable and definition.
      Patrick Steinhardt committed
    • cmake: try to detect threads library · 096a49c0
      While we already make use of the variable `${CMAKE_THREAD_LIBS_INIT}`,
      it is actually undefined due to us never including the "FindThreads"
      module in the CMakeLists.txt. It is rather curious as to why this has
      never triggered any error up to now, but it does in fact result in
      linking errors on some Unix platforms as soon as we split up our build
      instructions into multiple files.
      
      Fix the issue now to avoid future breakage by including the
      "FindThreads" module.
      Patrick Steinhardt committed
  10. 28 Jun, 2017 2 commits
  11. 23 Jun, 2017 1 commit
  12. 22 Jun, 2017 1 commit
    • cmake: Permit disabling external http-parser · 845f661d
      When attempting to build libgit2 as an isolated static lib, CMake
      gleefully attempts to use the system http-parser.  This is typically
      seen on Linux systems which install header files with every package,
      such as Gentoo.
      
      Allow developers to forcibly disable using the system http-parser with
      the config switch USE_EXT_HTTP_PARSER.  Defaults to ON to maintain
      previous behavior.
      
      Signed-off-by: Jason Cooper <jason@lakedaemon.net>
      Jason Cooper committed
  13. 13 Jun, 2017 3 commits
    • cmake: disable optimization on debug builds · a64532e1
      While our debug builds on MSVC platforms already tune the code optimizer
      to aid debugging code, all the other platforms still use the default
      optimization level. This makes it hard for developers on these platforms
      to actually debug code while maintaining his sanity due to optimizations
      like inlined code, elided variables etc.
      
      To help this common use case, we can simply follow the MSVC example and
      turn off code optimization with "-O0" for debug builds. While it would
      be preferable to instead use "-Og" supported by more modern compilers,
      we cannot guarantee that this level is available on all supported
      platforms.
      Patrick Steinhardt committed
    • cmake: set "-D_DEBUG" on non-Windows platforms · 61399953
      In our code base, we have some occasions where we use the "_DEBUG"
      preprocessor macro to enable additional code which should not be part of
      release builds. While we define this flag on MSVC platforms, it is
      guarded by the conditional `WIN32 AND NOT CYGWIN` on other platforms
      since 19be3f9e (Improve MSVC compiler, linker flags, 2013-02-13). While
      this condition can be fulfilled by the MSVC platform, it is never
      encountered due to being part of the `ELSE` part of `IF (MSVC)`.
      
      The intention of the conditional was most likely to avoid the
      preprocessor macro on Cygwin platforms, but to include it on everthing
      else. As such, the correct condition here would be `IF (NOT CYGWIN)`
      instead. But digging a bit further, the condition is only ever used in
      two places:
      
      1. To skip the test in "core::structinit", which should also work on
         Cygwin.
      2. In "src/win32/git2.rc", where it is used to set additional file
         flags. As this file is included in MSVC builds only, it cannot cause
         any harm to set "_DEBUG" on Cygwin here.
      
      As such, we can simply drop the conditional and always set "-D_DEBUG" on
      all platforms.
      Patrick Steinhardt committed
    • cmake: remove stale comment on precompiled headers · e94be4c0
      In commit 9f75a9ce (Turning on runtime checks when building debug under
      MSVC., 2012-03-30), we introduced a comment "Precompiled headers", which
      actually refers to no related commands. Seeing that the comment never
      had anything to refer to, we can simply remove it here.
      Patrick Steinhardt committed
  14. 07 Jun, 2017 1 commit
    • sha1dc: do not use standard includes · db1abffa
      The updated SHA1DC library allows us to use custom includes instead of
      using standard includes. Due to requirements with cross-platform, we
      provide some custom system includes files like for example the
      "stdint.h" file on Win32. Because of this, we want to make sure to avoid
      breaking cross-platform compatibility when SHA1DC is enabled.
      
      To use the new mechanism, we can simply define
      `SHA1DC_NO_STANDARD_INCLUDES`. Furthermore, we can specify custom
      include files via two defines, which we now use to include our
      "common.h" header.
      Patrick Steinhardt committed