Comments (6)
First, I should emphasize the provided CMake configuration allows a couple of ways to develop Boost.GIL, and not to use Boost.GIL.
The CMake configuration should be considered purely internal and as such it has started as a quick hack, gradually becoming more complex than initially intended.
As author of this CMake configuration, I eventually aim to thoroughly modernise it (you can review my PR proposing modern CMake configuration for GEOS library to have an overview of what kind of changes I'm going to make.
More specifically, there will be INTERFACE
targets with specific compilation flags for building in various development modes (eg. tests, UBSAN, warnings off, etc.).
I am also going to add Boost and GIL targets and link tests, examples against those. Howeer, since this is internal CMake configuration dedicated for Boost.GIL developers only, and not consumers, there will be no Boost::gil
. That is, I will not pollute Boost::
namespace which:
- is already used by
FindBoost.cmake
- may completely change, in both, CMake itself and Boost, with the advent of new CMake proposal for Boost (I'm sure you are very well aware of the ongoing initiative supervised by @robertramey).
- so I'm not going to make any public, consumer-oriented CMake configuration for Boost.GIL until CMake for Boost itself has not yet settled.
Thank you for your comments, I will keep the issues open as a reminder for future improvements.
from gil.
Just to clarify: I opened these issues exactly because I was hacking on gil (more precisely because I want to compile some boost libraries with a custom toolchain for a semi-embedded target) which is why I didn't say anything about installation. Having a target you can link against is not only helpful for external consumers, but also when creating your test or example applications. The Idea for Boost::gil
actually came from the video you linked, but I'd already be happy with a plain boost_gil
or somesuch.
But I completely understand if - in light of robert's initiative - you don't want to spend time refactoring the cmake files just to change them again, once a boost-wide solution comes up.
More specifically, there will be INTERFACE targets with specific compilation flags for building in various development modes (eg. tests, UBSAN, warnings off, etc.).
That is something I'd advise against. Let the toolchain file decide if a targets should be compiled with ubsan, against which standard library to link, what optimization flags to use, what compiler and c++ version to use a.s.o.. For a header only library, the only thing your targets needs to specify are dependencies and flags that are purely specific to your library (can't think of a good example right now).
from gil.
OK, thanks for the clarification
Having a target you can link against is not only helpful for external consumers
For the time being, I do not want to breed or encourage any external customers of Boost.GIL's CMake. And, I'm going to quite die hard for it, for the time being.
If one wants to use Boost.GIL with a project based on CMake, one needs to stick to FindBoost.cmake
or own solution.
More specifically, there will be INTERFACE targets with specific compilation flags for building in various development modes (eg. tests, UBSAN, warnings off, etc.).
That is something I'd advise against.
I disagree. Use of flags-only targets to manage variety of developer mode builds is not a breach of any (modern) CMake best practices. On the contrary, Kitware uses this technique itself (e.g. VTK-m).
For a header only library, the only thing your targets needs to specify are dependencies and flags that are purely specific to your library
That is exactly what I'm going to do. Those targets will provide "flags that are purely specific to your library. You seem to be missing my point. The CMake configuration is exclusively for those who want to develop and test Boost.GIL, and submit pull request, and they prefer CMake over Boost.Build.
Please, let's stop discussing rules of public consumer-oriented CMake configuration for a library in Boost.GIL. There is no such thing to discuss. And no, I will not accept any PRs with CMake changes that introduce anything for Boost.GIL consumers.
Certainly, this position may change ones Robert's initiative if completed.
from gil.
Please, let's stop discussing rules of public consumer-oriented CMake configuration for a library in Boost.GIL.
Well the thing with OS software is that your consumers are sometimes/often working on the library themselves (such as me). As I said (in the part you didn't quote) the changes suggested here and in the other issue are useful for the development of this library. But anyway, I absolutely understand you only want to provide cmake files for internal development and I also understand that I should keep my changes to myself - no worries.
Use of flags-only targets to manage variety of developer mode builds is not a breach of any (modern) CMake best practices.
Did I say it is a breach of any best practices (well actually, I sometimes feel like if you ask ten different people about best practices in cmake you get eleven different answers but that is another topic)?
It has simply been my experience that it makes development and testing much easier, if the library itself doesn't have to worry about all kinds of possible compilation modes and toolchains, because it is something you have to do over and over again for each lib (IIRC that is actually also something that is mentioned in the talk you linked to).
Instead, you can have a set of toolchain files with the configurations relevant to you (compiler(-version), standdard library (version and flavor), sanitizers, link type for runtime library, static analysis tools etc. ) and then you can compile and run the tests of any new cmake-based library you are developing/using without littering those CMakeFiles.txt with dozens of differently configured targets (or even different package management systems).
Again, just my personal experience - obviously nothing you have to agree with.
from gil.
@Mike-Devel I appreciate your comments. It's always good to be provoked to question and re-think own bits. I never say never. Meanwhile, let's keep this open.
(TBH, at this stage of my love and hate relation to CMake, the toolchain files I hate ;-))
from gil.
I've labelled this as work-in-progress as this idea is not dropped, but postponed until the CMake for Boost has been completed.
Apparently, some interesting CMake-ification efforts are ongoing thanks to @Mike-Devel & @pdimov, so chances are the GIL's own CMake configuration will need to be modified anyway. Let's wait and see.
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.