Comments (6)
I am all in to move to Boost.CI and standardized configuration that would help with the maintenance. I prefer a limited set of compilers:configurations to a CI that fails for obscure reasons.
It is likely that we will require C++17 as minimum standard some time soonish
OK with me, and I agree that we need to move forward with respect to the community.
As a user of Boost.GIL, I get my dev env (and the Boost libraries) from Conda and can use the latest compilers on all platforms, so dropping support for 5yo compilers is not a problem. I am not saying that we should.
from gil.
- We need to disable certain compilers
Yeah. I'd like to remove Clang 3.5, 3.6, 3.7 and 3.8 from the GitHub Actions (=GHA) workflows and would have done so already in #640 to get rid of building on Ubuntu 16.04 completely. GHA does not support Ubuntu 16.04 anymore anyway, so keeping it is not a viable option. And Clang version 3.8 and earlier are not available via the currently used APT repository anymore, even when switching to a newer Ubuntu version for builds. This means that there is no "easy" way to install those compilers via apt-get
during those workflows. However, I am not sure what guarantees Boost GIL or Boost in general makes to its users for supporting older compilers, so I decided not to remove the older Clang builds as part of #640.
For reference: https://releases.llvm.org/. Clang 3.5 was released in September 2014, almost eight years ago. Clang 3.8 was released in March 2016, i. e. six years ago.
PS: As a general idea, we should probably make sure that the existing CI pipelines pass (except for the outdated stuff that may potentially get removed). Otherwise we may just be migrating existing build failures to another CI configuration with boost-ci.
from gil.
PS: As a general idea, we should probably make sure that the existing CI pipelines pass (except for the outdated stuff that may
potentially get removed). Otherwise we may just be migrating existing build failures to another CI configuration with boost-ci.
Yes, this is an ideal plan. We, however, do what we can i.e. w.r.t. man power. So, your contributions to our CI are godsend.
I'd like to remove Clang 3.5, 3.6, 3.7 and 3.8 from the GitHub Action (...)
First, let's summarise where we currently are:
-
Boost.GIL became a C++11 library in 2018 (after grand merge and we still have a few items to do, see C++11 Modernization plan).
-
We have dropped support for GCC 4.8 after I asked the Boost community
what is usable version of GCC for C++11 support and the answer was: 4.8 core, 4.9 library, 5 without bugs
See #282
-
We are going to bump the minimum required C++ version and we have already issued the deprecation notice with Boost 1.75.0 (see https://github.com/boostorg/gil/blob/develop/RELEASES.md) - see discussion at #526.
We should follow similar plan w.r.t. to clang and any other compiler we support.
We should not arbitrarily or accidentally remove support for any compiler without prior notice.
It is likely that we will require C++17 as minimum standard some time soonish, but we need to be considerate and well-behaving part of Boost.
See the 2020 thread Shall we switch to C++17?/10/0465.php), where the most important part to consider is Peter Dimov's sensible suggestion that applies to any C++ version, not just C++03:
The suggested way forward is to allow library authors to declare C++03 support deprecated via a notice in the documentation and a message issued at compile time, then be allowed to drop C++03 support no earlier than two Boost releases later.
/cc @boostorg/gil-developers
from gil.
I prefer a limited set of compilers:configurations to a CI that fails for obscure reasons.
I agree.
Ideally, if the CI is defined in some sort of fan-out fashion like Boost.Geometry build on CircleCI, with inter-job or even inter-workflow dependencies,
For example, our GitHub Actions could run sequence of inter-dependant workflows:
minimal-core.yml
- build with single (first fullly C++17-compliant) version of GCC and Clang and MSVC against GIL core testsheaders-core.yml
- self-contained headers checkminimal-ext.yml
- likeminimal-core.yml
but for extensions (w/ simple I/O tests)headers-ext.yml
- likeheaders-core.yml
but for extensionsfull-core.yml
- core tests build with large variety of compilers/versions,cxxstd
-s, buildvariant
-s andaddress-model
-sfull-ext.yml
- likefull-core.yml
but for extensions (w/ full I/O tests)
I think this may be possible with GHA features like dependant jobs and workflow_call
or workflow_run
.
Such approach, which I think I'm in favour of, would justify resignation from the switch to boost-ci as we would have to have full control on the GHA workflows.
from gil.
I think it's a good idea to have separate pipelines for core / extensions and different groups of compilers / std. It will give use a much better idea of the location / severity of failing pipelines. I understand that Boost.CI is not flexible enough to implement this approach though.
from gil.
I have moved the planning towards C++14/17 to discussion here #676
from gil.
Related Issues (20)
- Add tests for PR #505 with RGB to HSL fix
- Refactor any_image tests after deprecating apply_operation in #656
- Remove C++11 build jobs from CI HOT 2
- Fix wrong pixel channel truncation in binary threshold and truncate threshold HOT 2
- Consider moving channel_convert_to_unsigned out of detail namespace
- color_convert_hsl / gcc-5~c++14: converting to std::tuple from initializer list would use explicit constructor constexpr std::tuple
- color_convert_rgb / gcc-5~c++14: converting to std::tuple from initializer list would use explicit constructor constexpr std::tuple
- color_convert_hsl.cpp and color_convert_rgb.cpp error: no matching constructor for initialization of std::vector<color_t>
- Allow implicit conversion from gray8_ptr_t to gray8_step_ptr_t HOT 3
- g++ 12.1.1 fails to compile Boost.GIL with -std=c++20 HOT 3
- unsued variable warning
- Convolution2d seems to be not correct. HOT 1
- stream device "tell" method absent! HOT 2
- Support for reading/writing 1 bit (black/white) BMP images? HOT 2
- Alpha-blending HOT 4
- Overflow in channel convertion HOT 2
- heap-buffer-overflow when using io-related functions HOT 1
- Running the convolve_2d.cpp test causes an alignment error on ARM
- About Enterprise Managed Users - GitHub Enterprise Cloud Docs
- https://docs.github.com/es/[email protected]/admin/monitoring-managing-and-updating-your-instance/updating-the-virtual-machine-and-physical-resources/upgrading-github-enterprise-server HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gil.