Bug 284084 - [NEW PORT] devel/reflect-cpp: C++-20 library for fast serialization, deserialization and validation
Summary: [NEW PORT] devel/reflect-cpp: C++-20 library for fast serialization, deserial...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL: https://rfl.getml.com/
Keywords:
Depends on:
Blocks:
 
Reported: 2025-01-15 17:00 UTC by Älven
Modified: 2025-01-31 23:52 UTC (History)
1 user (show)

See Also:
alster: maintainer-feedback+


Attachments
[PATCH] [NEW PORT] devel/reflect-cpp: C++-20 library for fast serialization, deserialization and validation (17.49 KB, patch)
2025-01-15 17:00 UTC, Älven
alster: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Älven 2025-01-15 17:00:14 UTC
Created attachment 256718 [details]
[PATCH] [NEW PORT] devel/reflect-cpp: C++-20 library for fast serialization, deserialization and validation

reflect-cpp is a C++-20 library for fast serialization, deserialization and validation using reflection, similar to pydantic in Python, serde in Rust, encoding in Go or aeson in Haskell.

reflect-cpp fills an important gap in C++ development. It minimizes boilerplate code and enhances code safety for seamless and efficient data exchange across system components.
Design principles for reflect-cpp include:

    Close integration with containers from the C++ standard library
    Close adherence to C++ idioms
    Out-of-the-box support for JSON
    Simple installation
    Simple extendability to other serialization formats
    Simple extendability to custom classes
    Being one of the fastest serialization libraries in existence, as demonstrated by our benchmarks


Poudriere testport: OK for [amd64 i386] * [142 141 134]                                                                                
                                                                                                                                       
Make test: 100% tests passed, 0 tests failed out of 193
Comment 1 Vladimir Druzenko freebsd_committer freebsd_triage 2025-01-31 23:14:40 UTC
What ports will use this library?
Comment 2 Älven 2025-01-31 23:18:37 UTC
(In reply to Vladimir Druzenko from comment #1)
What ports will use this library?

I made it for any port who would like to.
Comment 3 Vladimir Druzenko freebsd_committer freebsd_triage 2025-01-31 23:31:31 UTC
This makes little sense. There are thousands of different small libraries. Simply adding them all would only increase the load on committers without any benefit. Sometimes we don't have time to commit even trivial updates from maintainers: https://bugs.freebsd.org/bugzilla/page.cgi?id=dashboard.html&days=365
There is even a practice of removing a library from ports if there is not a single port left that uses it. Therefore, I would not add just a library without consumers.
This does not apply to ports that contain, in addition to the library, some software that uses this library.
This also applies to the other two PRs: https://bugs.freebsd.org/284063 https://bugs.freebsd.org/284070
Comment 4 Älven 2025-01-31 23:43:36 UTC
Yes, I may understand the committers being overloaded. Why couldn't then maintainers do commit at least trivial update patches by themselves? This would offload a lot of work from the committers to be able to focus on more difficult/important things…
Comment 5 Vladimir Druzenko freebsd_committer freebsd_triage 2025-01-31 23:52:56 UTC
I already had this idea: somehow allow some maintainers to commit to their ports themselves. It's something between just a port maintainer and a committer to ports. But I can't imagine how to implement it both organizationally and technically.