emileclarkb/hammer
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
hammer/appveyor.yml

21 lines
511 B
YAML
Raw Normal View History

windows build: Add build scripts + appveyor.yml In order to guarantee that Hammer can build on Windows, an appveyor.yml and associated build scripts will build hammer and its examples. The idea is that as soon as the appveyor.yml exists in the repository, pull requests that would impede Windows portability would be immediately detected. The scripts expect CL.EXE to be in the path, and will produce their results in build/ The highest level of warning is enabled on CL.EXE, minus warnings that bring CL.EXE to a level that ressembles C99. The only notable warning that was disabled is the one that tells you about implicit truncating conversions. Hammer's source code has quite a few implicit conversions say from a 64bit unsigned integer to a integer of a lesser size (signed or otherwise)
2015-08-09 15:20:43 +02:00
platform:
- x86
- x64
version: 1.0.{build}
os: Visual Studio 2015
build_script:
- '@echo off'
- setlocal
- ps: >-
If ($env:Platform -Match "x86") {
$env:VCVARS_PLATFORM="x86"
} Else {
$env:VCVARS_PLATFORM="amd64"
}
Add workaround for VS2015 so that appveyor works It seems Appveyor's images have been changed. The builds could not find standard library headers anymore. It seems to be an interaction between MS' scripts and the Windows Driver Kit that is installed there. One way to disable this interaction is to rename the `wdf` folder to some other name. See: - http://stackoverflow.com/questions/31862627/vs2015-cl-cant-find-crt-libs-stido-h-ctype-h-etc-when-building-on-command-l - http://help.appveyor.com/discussions/problems/3062-problem-with-new-updates-visual-studio-2015-and-cmake - https://github.com/appveyor/ci/issues/414
2015-09-20 17:16:43 +02:00
ren 'C:\Program Files (x86)\Windows Kits\10\include\wdf' '00wdf'
windows build: Add build scripts + appveyor.yml In order to guarantee that Hammer can build on Windows, an appveyor.yml and associated build scripts will build hammer and its examples. The idea is that as soon as the appveyor.yml exists in the repository, pull requests that would impede Windows portability would be immediately detected. The scripts expect CL.EXE to be in the path, and will produce their results in build/ The highest level of warning is enabled on CL.EXE, minus warnings that bring CL.EXE to a level that ressembles C99. The only notable warning that was disabled is the one that tells you about implicit truncating conversions. Hammer's source code has quite a few implicit conversions say from a 64bit unsigned integer to a integer of a lesser size (signed or otherwise)
2015-08-09 15:20:43 +02:00
- call "%VS140COMNTOOLS%\..\..\VC\vcvarsall.bat" %VCVARS_PLATFORM%
- call tools\windows\build.bat
Don't build all of Hammer on AppVeyor just now Since the port is not finished yet, we remove some source files and the compilation of examples.
2015-08-09 18:40:44 +02:00
# FIXME(windows) TODO(uucidl): reactivate examples
# - call tools\windows\build_examples.bat
windows build: Add build scripts + appveyor.yml In order to guarantee that Hammer can build on Windows, an appveyor.yml and associated build scripts will build hammer and its examples. The idea is that as soon as the appveyor.yml exists in the repository, pull requests that would impede Windows portability would be immediately detected. The scripts expect CL.EXE to be in the path, and will produce their results in build/ The highest level of warning is enabled on CL.EXE, minus warnings that bring CL.EXE to a level that ressembles C99. The only notable warning that was disabled is the one that tells you about implicit truncating conversions. Hammer's source code has quite a few implicit conversions say from a 64bit unsigned integer to a integer of a lesser size (signed or otherwise)
2015-08-09 15:20:43 +02:00
- exit /b 0
Reference in a new issue Copy permalink