Abandoned?

[rjzak]

Since there hasn't been any activity with the code base in almost a year, is this project abandoned?

This question was also asked on the mailing list without response. https://groups.google.com/g/cerealcpp/c/PW1NHZdFUKU/m/jvnMwlI0AwAJ

[AzothAmmo]

cereal has not been abandoned, maybe neglected is a better word? Our CI pipeline has been broken for a while and I haven't taken the time to fix it (nor has anyone else), which is making it difficult to merge pull requests. cereal supports a wide range of compilers and systems right now and ensuring that we don't break anything is fairly important.

I have been tempted to drop support for some older compilers - we don't have any usage statistics but I have to imagine that the number of users on something like GCC < 5 or MSVC13 is quite low now.

[lordvictory]

This library is an amazing piece of work.

I actively use this serialization library. IMHO, it's the best and easiest to work with. I usually use it in embedded systems for custom RPC, by creating a templated class that encodes/decodes all messages sent and received using the included portable binary format. On a 1Ghz iMX8 w/gigabit ethernet it takes approx. 1 millisecond round trip between 2 systems for a single request/response cycle.

In regards to compiler support, I'd certainly drop any compiler version that didn't have full C++11 support (including full C++11 library support). In my experience, full library support oftens lags by several versions from when they say the compiler may support it, particularly for some embedded systems.

In my current project, using newer compilers presents some issues in regards to many warnings, mostly due to language changes between C++11 and C++20 with g++ v13.2.

Would be nice to see the library updated a bit for better compatibility with the newer language standards.

[sjrdc]

@AzothAmmo so are there any plans on how to take this project forward? I think it is a really great project that has a lot of practical value and usage, and it would be a pity to let it slip into further neglected and then abandoned state.

Can we discuss what is needed to get it going again?

[sjrdc]

I am fixing linux CI with #846; let's meanwhile try to come up with some directions, for example

• create an organization to take this project forward and establish a broader governance structure for it
• decide on a fork and take the fork further

[AzothAmmo]

I'll be able to review your MR next week.

[TheOnlyJoey]

Also any way to contribute to the project financially for those with limited time who still want to contribute?
Thanks ^_^

[AzothAmmo]

I've merged the linux CI fixes - will still need to address the osx / windows stuff but this is good progress for getting into a more normal cadence of reviewing MRs.

[sjrdc]

For macOS, the solution can be as easy as adopting the compilers available in the latest macOS docker image. Is that an acceptable direction? What is the significance of testing the current old xcode versions?

[AzothAmmo]

The versions in there are simply those that were current when the tests were written, more or less. I'm not really familiar with macOS development so I don't know which versions still make sense to target.

[rjzak]

Maybe just test on current and current - 1?

[sjrdc]

The versions in there are simply those that were current when the tests were written, more or less. I'm not really familiar with macOS development so I don't know which versions still make sense to target.

Good, let's adopt the same going forward then

[lordvictory]

Sorry hadn't replied...was on vacation.

I use OSX systems for my general workstation, which I use for all my C++ development. But I don't normally do MacOS development, I usually work on Linux systems these days.

Having said that, I do have the MacOS Command Line Devkit installed, so it shouldn't be much of a chore to attempt command line builds for MacOS. I usually use CMake for building, but I'm not a real maven with it, and try to mostly keep things simple to get the job done.

Just let me know exactly what you'd like done on OSX. I'm currently running Sonoma 14.5.

One of the things I'd like to see done, and perhaps participate in, would be some updating of the routines that do the I/O. C++20 has a number of features that might be utilized for better performance, like std::span<> or std::format_to(). There are more options that are faster and more generic in C++20.

[madscientist42]

C++20 might be a bit of a bridge too far unless you can option for both something like 11 and then 20 as a gearshift. I mean, it is already fast to begin with. ;)

Good to see life here. About to add a Yocto recipe for things here.

[patlecat]

I'd suggest investing time into going to C++23 right away since this is going to take up some time and efforts anyhow. Then you'll be good for some years.

[AzothAmmo]

There's definitely a lot of nice stuff in C++20 and newer, but I don't see moving to those for the broad library implementation at this time. We can, and should, support standard library types introduced in newer versions of C++ however. I also think that, depending on the benefits, having some alternative implementations for portions of the library is a okay so long as backwards compatibility is kept. You can see some of the complication this would cause by looking for the CEREAL_OLDER_GCC macro (or by looking at some boost source code).