Refactor common settings into .props files. Enables building full
PlatformToolset, Platform, Configuration matrix easily.
Also update the appveyor file. Technically we no longer need different
images (could just have a single vs2022 image which is executed multiple
times in parallel, or so)
Closes#1116
The files needed for Continuous Integration (AppVeyor, Travis) are not
meant for public consumption, so clean up the root directory by moving
these files underneath .private.
Create a single build script that is leveraged by both AppVeyor and
Travis. This script replaces the previous 'travis-autogen.sh' file and
enables additional compiler warnings that should provide additional
coverage for all build environments.
Update the Travis configuration file to absorb the Brewfile and update
the Xcode images. Per warnings from Travis, Xcode6.4 is obsolete, thus
replace it with Xcode7.3. Additionally remove the "gcc" variants for the
macOS builds. The builds never used gcc to begin with and actually using
gcc causes build errors due to Clang-specific pragmas in the IOKit
header files.
Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
Using the 'for' construct allows the specification of a more complex
build matrix. This additionally simplifies the builds using MinGW and
Cygwin because the build script can be unified and does not require
checking for the 'Release' configuration.
This change also extends the MinGW builds to cover both 32-bit and
64-bit builds using GCC versions 6.3.0 and 8.1.0, respectively. The
Cygwin builds were similarly extended to include 64-bit build coverage.
Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
Apparently AppVeyor dropped support for some compilation environments in
the 2017 image, so fall back to the 2015 image and forego compilation
with the newer tools.
Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
There appears to be no need for the WinCE backend anymore, and it is
increasingly difficult to keep healthy as the rest of the library
changes.
Require at least Visual Studio 2013 to compile. This simplifies matters
as there is some semblance of C99 support there.
Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
- Changes in platform configuration, x86 breaks the build
- Solution file does not contain platform for Any CPU, fixing it to Win32
- Added Multiple solutions to appveyor configuration file
- Added batch script for VS2010 builds
- Added fixes to appveyor.bat file and appveyor.yml
- Fixes for Platform and Configuration in appveyor.bat
- Fixed windows exit code, Appveyor reports exit on succesful build
- Multiple Builds in same platform and configuration, fixed it
- Added appveyor configuration to compile using MinGW 32-bit and 64-bits
- Minor Fixes for batch file and Added cygwin build script
Signed-off-by: Ludovic Rousseau <ludovic.rousseau@free.fr>
- Changes in platform configuration, x86 breaks the build
- Solution file does not contain platform for Any CPU,fixing it to Win32
- Added Multiple solutions to appveyor configuration file
- Added batch script for VS2010 builds
- Added fixes to appveyor.bat file and appveyor.yml
- Fixes for Platform and Configuration in appveyor.bat
- Fixed windows exit code, Appveyor reports exit on succesful build
- Multiple Builds in same platform and configuration,fixed it
