We’ve made a backwards-compatibility release v0.9.2 and are now beginning what will likely be pretty substantial changes in terms of baseline requirements for Cinder.
Our immediate goals:
Remove Boost as a requirement on all platforms
This will require dropping ci::JsonTree. We will likely create an opt-in inclusion of nlohmann::json mostly for samples.
Dropping VC2015 and moving to VC2019-ony support on MSW
Dropping Win32 and moving to x64-only support on MSW
Requiring C++14 on all platforms, and defaulting to C++17 on VC2019.
Requiring Ubuntu version 16.04 or later, which ships with GCC 5.3.1 (and supports C++14)
Dropping support for older SBC’s, including the Jetson TK1, and Raspberry Pi’s preceding the 4.
The above (specifically the Pi <4) allows us to drop OpenGL ES 2
Now is the time to speak up if any of these changes would create problems for upcoming projects, recognizing that 0.9.2 is designed to accommodate projects which require older compilers.
This is great! I’m excited about the push for more modern compilers and features and for dropping ci::JsonTree. Do you guys have a rough plan in mind yet for how to deal with the opt-in replacement? In particular, I’d be curious about how to point multiple projects to the same central Cinder repo and manage projects/blocks that require/don’t require that opt-in lib. I could imagine this having an impact on a few blocks that we use, but none should be a big deal to upgrade.
@benjaminbojko
The plan will be to include nlohmann::json in the core distribution, and then provide a "cinder/JsonNlohmann.h" which will provide a few convenience methods for interfacing with ci::fs::path and the like. Cinder itself won’t use the library directly, and there’s no cost to users if you have a different JSON library you prefer.
@gaoyu
GL 4.6 is not supported in 0.9.2 conveniently, but will be shortly in 0.9.3dev when we switch from glload to GLAD.
May I also suggest to upgrade the required cmake version to at least 3.5 (default on ubuntu 16.04) and preferably 3.10 (default on ubuntu 18.04) or even later. CMake is extremely easy to upgrade these days (https://blog.kitware.com/ubuntu-cmake-repository-now-available/) and there have been a lot of improvements since the 2.8 days, that allow simplification of many cmake scripts.
Regarding json: I rarely use cinder, so don’t place too much weight on this, but I’d prefer if cinder did not include that library in its distribution. I usually have my own copy of that lib in my projects (either cloned from github or through a package manager like conan or vcpkg) and if cinder ships it’s own copy, that creates the risk of version mismatches.
The more 3rd party libraries cinder ships as part of the core distribution, the harder it is to integrate it into package management systems or existing projects that are not build around cinder from the start.
I disagree, I think JSON loading is fundamental to a good volume of the work that gets done with cinder and thus it should be built in. I am sympathetic to versioning issues though, so i wonder if there’s something that could be done via preprocessor defines to prevent dragging in libs on an opt-in basis, but defaulting to the common case?
Let me put it this way: Personally I don’t think any library has any business bundling and shipping 3rd party dependencies - at least not without a way to opt out of it. However, I understand that cinder is more seen as a eco system/sdk than just a simple library and the needs of the typical cinder developer is probably different than mine.
If it is important that this is shipped as part of core cinder, I’d prefer one of the following solutions:
Make inclusion optional e.g. by
Include it as a git submodule - people that prefer to use their own version can then simply not clone it and there is no danger of mismatch.
Or at least don’t put it into the regular cinder/include directory, but a separate one that can easily be excluded from the search.
Completely Internalize the library:
Put the code into the cinder namespace
Prefix at least the header guard macros with CINDER
Change the name of the json.hpp file and/or the directory in which the file is located
Best I can tell, preprocessor guards don’t really help here, because even if the cinder headers guard against it, cinder/nlohmann/json.hpp will still end up in the include path of my app and might override the path I specified.
But again - all this is preconditioned on the question if you even wan to support a configuration where a user wants to use a different version of that library than what is shipped with cinder.
I like using submodules for these thirdparty dependencies because they make it much easier to upgrade. However the downside is that if we need to make any modifications, we need to fork the repo, which is a bit of a drag.
Considering whether we should or should not ship the library - we already need something at least for samples, and it is also nice going into a project working with new developers, and we are using the same libraries since they ship with cinder as is. Also for those unaware, we’ve been shipping jsoncpp ever since one of the earliest releases, which is what many of us have been using on client projects. Seems that nlohmann is now favored, and personally I couldn’t care which one is used, but I do agree we need json library and also shouldn’t spend our time re-coding that, or even modifying a thirdparty json lib unless it’s absolutely beneficial.
I don’t see the ‘include path mash-up’ issue as a huge deal in this case, as it can always be controlled by the way you set up your project. Though one option to be ultra clear with include paths would be to include the nlohman in some folder like cinder/include/thirdparty, and you need to add that to your path to use the version shipped by cinder. This is how I have things arranged in my mason toolbox, although it is a bit simpler because I use a property sheet that has a CINDER_PATH defined.
Also don’t see the #ifndef CI_EXCLUDE_NLOHMANN_JSON step helping much here since there’s no usage of json in libcinder itself.
This will require dropping ci::JsonTree . We will likely create an opt-in inclusion of nlohmann::json mostly for samples.
Dropping VC2015 and moving to VC2019-ony support on MSW
Dropping Win32 and moving to x64-only support on MSW
Requiring C++14 on all platforms, and defaulting to C++17 on VC2019.
All these changes will be very welcome, as will the switch to GLAD from glload! Regarding removing Boost – I assume you’ll continue to include the asio library (either in Boost or “standalone” form) for serial and networking things (and OSC)?
And you’ll also continue to use GLM (presumably a newer version)?
Would be nice if the Mac version also defaulted to C++17, so we can easily use things like std::optional and std::variant (especially now that Boost will be gone and with it the easy use of the boost:: alternatives). But I guess it should just work fine if I manually switch to C++17 in the Xcode project (this currently works so I suppose it should continue to ).
cinder ships with the standalone asio library so it always uses that, and I believe it is eventually supposed to land in STL, at which point it’d use the platform specific versions.
GLM is still the core math library. I think it was also recently updated.
MacOS defaulting to C++17, I suppose that means defining what the minimum OS target is, and I’m not familiar with things on this front concerning recent Xcode toolsets. However, I think that if you go with the cmake path on Mac, you should be able to define what C++ version you need during configuration, and libcinder would/should respect this.
9.2 is looking great. Really happy to move on to C++17.
Now that Cinder is using GLAD… I think it would be really nice to include Paul’s reverse Z option and also have a sleek new sample showing off the new GLAD GL Extension features as well. I don’t know what I’d do without reverse Z now actually. It’s really great for large spaced scenes and zfighting. GTA is known to have used it for example and I’ve found that It’s really good for integrating raymarched shaders more accurately.
Here’s a video of Paul’s demo showing the obvious benefits of reverse z and he talks about implementing it with his fork of Cinder easily in this post .
no_other_alias,I just built cinder from source and first thing I did was implement vinjn’s Vulkan Cinder Block
Really excited about all this working straight away actually. Also relieved that we don’t need to have a separate build or complete rehaul of cinder. I even replaced it with the newer Vulkan release without trouble. I think, since boost is gone, I just had to replace a single boost.string.trim function in one file but that was it. If I’m not mistaken, using SPIRV and OGLcompiler, we can use both opengl and Vulkan? Cool stuff vinjn! I might finally dive into Vulkan now actually…
Great news! I am looking at the Android build system side of things and a lot has changed since the last commits on master. NDK21 now supports C++17 as well, and Android has its own native implementation of Vulkan. I’m just getting my head around the changes to the CMake & gradle build scripts and it’s starting to come together nicely now. I think we can finally get decent support for Android, on newer devices at least!
I’m curious to see whether the Vulkan Cinder Block will play nice with Android, might need a bit of massaging but hopefully not much - I’ll keep you posted!
I’m curious on the Android developments as well. Haven’t gotten to it yet but excited to make some stuff. I finally ditched apple… it was like getting out of an abusive relationship.
As for 9.3… I’m gonna at least attempt to start trying to put bindless buffer/command buffer alternatives into cinder… we’ll see how I fare. I think it would be a huge benefit to the core.
).