POC: Self-contained headers #1423
Conversation
real-or-random
added
ci
build
refactor/smell
meta/development
|
Interesting! This raises the question: Should self-containedness be tested in VERIFY mode, or non-VERIFY mode, or both? I believe at least in VERIFY mode because the goal here will be to help development tooling (e.g., clangd), and development is typically more convenient in VERIFY mode. Otherwise all Of course, we could manage to make this happen in both modes without too much hassle, that will be ideal. This is related to #1039, where I suggested something like this. |
I've been working on this branch a few months but decided to PR it now as I feel it might help with #1421 (comment). |
| SECP256K1_FE_VERIFY_FIELDS | ||
| #ifdef VERIFY | ||
| int magnitude; | ||
| int normalized; | ||
| #endif | ||
| } secp256k1_fe; |
There was a problem hiding this comment.
Have you tried/considered including field.h instead?
There was a problem hiding this comment.
Doesn't it create a circular dependency?
There was a problem hiding this comment.
In some sense, yes, but it's not a problem because the include guards should break any loops.
If you take that to the extreme, we could also have a single headers.h that includes all internal headers and include headers.h (almost) everywhere. That's a rather simple solution. I'm not convinced that this is very elegant, but it gets the job done...
There was a problem hiding this comment.
it's not a problem because the include guards should break any loops.
Right. But not for renaming a header to a source file. It is not clear (at least for me) how to make it meaningful. FWIW, I've already tried the testing script that keeps an original header unmodified.
There was a problem hiding this comment.
Right. But not for renaming a header to a source file. It is not clear (at least for me) how to make it meaningful.
You mean problems will occur if we move code from a header to a source file?
FWIW, I've already tried the testing script that keeps an original header unmodified.
I don't understand. Can you rephrase?
There was a problem hiding this comment.
Right. But not for renaming a header to a source file. It is not clear (at least for me) how to make it meaningful.
You mean problems will occur if we move code from a header to a source file?
Yes. I mean:
mv src/field_10x26.h src/field_10x26.c
gcc -c src/field_10x26.c -o src/field_10x26.oThat effectively renders src/field_10x26.h unavailable.
FWIW, I've already tried the testing script that keeps an original header unmodified.
I don't understand. Can you rephrase?
A modified script looks like that:
cp src/field_10x26.h src/field_10x26.c
gcc -c src/field_10x26.c -o src/field_10x26.o
This PR adds a tool that verifies every header whether it is self-contained.
As an example, the
field_5x52.handfield_10x26.hheaders have been refactored to get self-contained.