As discussed on Slack and Zulip, ML-DSA needs to stop forking eurydice_glue.h, because
i) this creates additional work for libcrux maintainers: instead of just benefiting from the latest changes in eurydice_glue.h, any change in eurydice_glue.h results in a broken build on the libcrux-ml-dsa side until the libcrux maintainers manually propagate changes. This creates more work to upgrade to a newer toolchain and is just tedious, difficult work.
ii) this breaks the circus-green build, which would otherwise keep ml-dsa green, except we can't because any change in upstream eurydice_glue.h is ignored by ml-dsa
The plan on record (per Slack discussion) is to have the big eurydice_glue.h split into several sub-headers, each for one piece of functionality. Then, eurydice.h includes all of the sub-headers, and all ml-dsa needs to do is maintain their own eurydice.h that only includes the parts of interest.
This is what I sketched on slack:
// eurydice.h
#include <eurydice/base.h> // C++ HELPERS, GENERAL-PURPOSE STUFF, EURYDICE_CFIELD, EURYDICE_CLITERAL
#include <eurydice/slice.h> // Eurydice_slice*, EURYDICE_SLICE*, Eurydice_array*
#include <eurydice/dst.h> // SUPPORT FOR DSTs
#include <eurydice/core.h> // CORE STUFF
#include <eurydice/iterators.h> // ITERATORS
#include <eurydice/strings.h> // STRINGS
#include <eurydice/unsafe.h> // UNSAFE CODE
#include <eurydice/experimental.h> // everything else
I believe some of these changes are in franziskus/c-glue-split. Let's talk here about what needs to happen in order to upstream these changes.
Thank you.
As discussed on Slack and Zulip, ML-DSA needs to stop forking eurydice_glue.h, because
i) this creates additional work for libcrux maintainers: instead of just benefiting from the latest changes in eurydice_glue.h, any change in eurydice_glue.h results in a broken build on the libcrux-ml-dsa side until the libcrux maintainers manually propagate changes. This creates more work to upgrade to a newer toolchain and is just tedious, difficult work.
ii) this breaks the circus-green build, which would otherwise keep ml-dsa green, except we can't because any change in upstream eurydice_glue.h is ignored by ml-dsa
The plan on record (per Slack discussion) is to have the big eurydice_glue.h split into several sub-headers, each for one piece of functionality. Then, eurydice.h includes all of the sub-headers, and all ml-dsa needs to do is maintain their own eurydice.h that only includes the parts of interest.
This is what I sketched on slack:
I believe some of these changes are in franziskus/c-glue-split. Let's talk here about what needs to happen in order to upstream these changes.
Thank you.