WIP no submodules

[biojppm]

No description provided.

[github-advanced-security]

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[coveralls]

Pull Request Test Coverage Report for Build 14553906133

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 97.578%

---

Totals
Change from base Build 14417824626:	0.0%
Covered Lines:	11564
Relevant Lines:	11851

---

💛 - Coveralls

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.62%. Comparing base (c1d0047) to head (eac82f8).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #512   +/-   ##
=======================================
  Coverage   97.61%   97.62%           
=======================================
  Files          46       46           
  Lines       13651    13658    +7     
=======================================
+ Hits        13326    13333    +7     
  Misses        325      325           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[marcalff]

@biojppm

If I understand correctly, the c4core submodule is replaced by a copy of the c4core repository, correct ?

Why is this desirable, and what issue does this resolve ?

Do you plan to remove the c4core repository and only maintain it within rapidyaml, and if not, how will the fixes from c4core be applied to rapidyaml (beside manually) ?

Please clarify the intent here, I am really worried about this change.

[biojppm]

If I understand correctly, the c4core submodule is replaced by a copy of the c4core repository, correct ?

Yes, with some details to it:

• this PR removes the c4core submodule, and copies c4core code into the rapidyaml tree, to two different dirs:
  • ext/c4core.src: c4core code used in the rapidyaml library
  • ext/c4core.dev: c4core code used used by tests/benchmarks
    Doing this makes the standalone library marginally smaller, and enforces the standalone default of rapidyaml bypassing the submodule. So most users (which don't care about c4core itself) will now see rapidyaml as a plain project without extra dependencies or submodules.
• this PR retains the existing option to compile against a full instance of the c4core library, thus ignoring the in-source copy under ext/c4core.src and ext/c4core.dev
  • the default is still to compile in standalone mode (ie c4core part of rapidyaml)
  • the pre-existing cmake option RYML_STANDALONE still enables users to build rapidyaml against a previously build c4core library (like in the ubuntu packages where rapidyaml depends on c4core).
• the amalgamation tool should work just as before

---

Why is this desirable, and what issue does this resolve ?

I have had repeated feedback that the c4core submodule makes it impossible for some people to use rapidyaml, either because it contains submodules, or because c4core is a dependency boogeyman.

While I disagree with both of these reasonings, it is not for me to dispute their choice.

So I am removing these reasons by making the c4core code really standalone in rapidyaml, while striving to retain all current existing workflows.

---

Do you plan to remove the c4core repository and only maintain it within rapidyaml

No, not at all. c4core will remain just as it is, in https://github.com/biojppm/c4core.

and if not, how will the fixes from c4core be applied to rapidyaml (beside manually) ?

This PR adds a helper makefile to simplify the workflow, with two main approaches:

• create an in-source clone of c4core (parallel to the existing copies, under the old location of the submodule ext/c4core) and...
• importing changes from c4core clone to rapidyaml copies
• exporting changes from rapidyaml copies to c4core clone
• check sync status.

The CI will enforce that the in-source c4core copy is in sync with the target commit hash (just like a submodule dirty status).

While this PR is still a WIP, it will eventually contain instructions on how to use the makefile to accomplish these steps.

---

Please clarify the intent here, I am really worried about this change.

Thanks for looking into this, I truly appreciate.

I am still working in this PR, so this is truly the proper time to start offering feedback. I have made a conscious effort to retain all existing usage scenarios, but if there is something I'm overlooking, I'd like to hear about it.

And FWIW, after getting this PR ready and green, I will let it linger for some weeks before merging it.

[biojppm]

@marcalff

The makefile helper to sync with c4core is at ext/Makefile, and the README with instructions will be at ext/README.md.

The file enforcing the c4core version is at ext/c4core.mk.

[marcalff]

@biojppm

Thanks for the context and clarifications, it helps.

The reason I care in particular is because I now have a dependency on rapidyaml, as you may have noticed already.

If not, it comes from:

• [CONFIG] Implement file configuration open-telemetry/opentelemetry-cpp#2481