Merge pull request #2136 from aokellermann/CircleCI_GCC_BleedingEdge

Add bleeding edge GCC to CI
This commit is contained in:
Niels Lohmann 2020-05-26 12:39:42 +02:00 committed by GitHub
commit 25aab7ee41
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 34 additions and 3 deletions

View file

@ -1,6 +1,6 @@
version: 2
jobs:
build:
build_stable:
docker:
- image: debian:stretch
@ -22,3 +22,33 @@ jobs:
- run:
name: Execute test suite
command: 'cd build ; ctest --output-on-failure -j 2'
build_bleeding_edge:
docker:
- image: archlinux
steps:
- checkout
- run:
name: Install required tools
command: 'pacman -Sy --noconfirm base base-devel gcc git cmake'
- run:
name: Show versions
command: 'g++ --version ; uname -a; cmake --version'
- run:
name: Run CMake
command: 'mkdir build ; cd build ; cmake ..'
- run:
name: Compile
command: 'cmake --build build'
- run:
name: Execute test suite
command: 'cd build ; ctest --output-on-failure -j 2'
workflows:
version: 2
build_and_test_all:
jobs:
- build_stable
- build_bleeding_edge

View file

@ -66,6 +66,6 @@ To make changes, you need to edit the following files:
The following areas really need contribution:
- Extending the **continuous integration** toward more exotic compilers such as Android NDK, Intel's Compiler, or the bleeding-edge versions of GCC or Clang.
- Extending the **continuous integration** toward more exotic compilers such as Android NDK, Intel's Compiler, or the bleeding-edge versions Clang.
- Improving the efficiency of the **JSON parser**. The current parser is implemented as a naive recursive descent parser with hand coded string handling. More sophisticated approaches like LALR parsers would be really appreciated. That said, parser generators like Bison or ANTLR do not play nice with single-header files -- I really would like to keep the parser inside the `json.hpp` header, and I am not aware of approaches similar to [`re2c`](http://re2c.org) for parsing.
- Extending and updating existing **benchmarks** to include (the most recent version of) this library. Though efficiency is not everything, speed and memory consumption are very important characteristics for C++ developers, so having proper comparisons would be interesting.

View file

@ -1085,7 +1085,7 @@ auto cbor = json::to_msgpack(j); // 0xD5 (fixext2), 0x10, 0xCA, 0xFE
Though it's 2020 already, the support for C++11 is still a bit sparse. Currently, the following compilers are known to work:
- GCC 4.8 - 10.0 (and possibly later)
- GCC 4.8 - 10.1 (and possibly later)
- Clang 3.4 - 10.0 (and possibly later)
- Intel C++ Compiler 17.0.2 (and possibly later)
- Microsoft Visual C++ 2015 / Build Tools 14.0.25123.0 (and possibly later)
@ -1142,6 +1142,7 @@ The following compilers are currently used in continuous integration at [Travis]
| GCC 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) | Ubuntu 18.04.4 LTS | GitHub Actions |
| GCC 8.4.0 (Ubuntu 8.4.0-1ubuntu1~14.04) | Ubuntu 14.04.5 LTS | Travis |
| GCC 9.3.0 (Ubuntu 9.3.0-11ubuntu0~14.04) | Ubuntu 14.04.5 LTS | Travis |
| GCC 10.1.0 (Arch Linux latest) | Arch Linux | Circle CI |
| MSVC 19.0.24241.7 (Build Engine version 14.0.25420.1) | Windows-6.3.9600 | AppVeyor |
| MSVC 19.16.27035.0 (15.9.21+g9802d43bc3 for .NET Framework) | Windows-10.0.14393 | AppVeyor |
| MSVC 19.25.28614.0 (Build Engine version 16.5.0+d4cbfca49 for .NET Framework) | Windows-10.0.17763 | AppVeyor |