1. 23 Nov, 2019 1 commit
  2. 22 Nov, 2019 1 commit
  3. 20 Jul, 2019 4 commits
    • azure: avoid executing compiler if there is none · 1be4f896
      Until now, we always had the CC variable defined in the build.sh
      pipeline. But as we're about to migrate the Windows jobs to Bash, as
      well, those will not have CC defined and thus we cannot use "$CC" to
      determine the compiler version.
      
      Fix this by only executing "$CC" if the variable was set.
      Patrick Steinhardt committed
    • azure: explicitly specify CMake generator · 8e356f48
      We currently specify the CMake generator as part of the CMAKE_OPTIONS
      variable. This is fine in the current setup, but during the conversion
      to drop PowerShell scripts this will prove problematic for all
      generators that have spaces in their names due to quoting issues.
      
      Convert to use an explicit CMAKE_GENERATOR variable that makes it easier
      to get quoting right.
      Patrick Steinhardt committed
    • azure: fix building in MinGW via Bash · d8e85d57
      Azure Pipelines supports bash tasks on Windows hosts due to it always
      having Git for Windows included. To support this, the Git for Window
      directory is added to the PATH environment to make the bash shell
      available for execution. Unfortunately, this breaks CMake with the MinGW
      generator, as it has sanity checks to verify that no bash executable is
      in the PATH. So we can either remove Git for Windows from the path, but
      then we're unable to execute bash jobs. Or we can add it to the path,
      but then we're unable to execute CMake with the MinGW generator.
      
      Let's re-model how we set the PATH environment. Instead of setting up
      PATH for the complete build job, we now set a variable "BUILD_PATH" for
      the job. This variable is only being used when executing CMake so that
      it encounters a sanitizied PATH environment without GfW's bash shell.
      Patrick Steinhardt committed
    • azure: move build scripts into "azure-pipelines" directory · ffac520e
      Since we have migrated to Azure Pipelines, we have deprecated and
      subsequentally removed all infrastructure for AppVeyor and
      Travis. Thus it doesn't make a lot of sense to have the split
      between "ci/" and "azure-pipelines/" directories anymoer, as
      "azure-pipelines/" is essentially our only CI.
      
      Move all CI scripts into the "azure-pipelines/" directory to have
      everything centrally located and to remove clutter in the
      top-level directory.
      Patrick Steinhardt committed
  4. 13 Feb, 2019 1 commit
  5. 10 Sep, 2018 1 commit
  6. 06 Sep, 2018 1 commit
  7. 06 Aug, 2018 1 commit
  8. 03 Aug, 2018 1 commit
  9. 26 Jul, 2018 3 commits