core/lib: split kernel defines by its concerns#18882
Conversation
|
how about we put them in one file per macro, named e.g., |
Murdock results✔️ PASSED 045bd7a core/lib: split kernel defines by its concerns
ArtifactsThis only reflects a subset of all builds from https://ci-prod.riot-os.org. Please refer to https://ci.riot-os.org for a complete build for now. |
thought about that - but then i saw we can keep the NORETURN from conflicting with similar macros defined in pkgs if we just split by general concern. |
24f2943 to
045bd7a
Compare
yes, but, if they're all in one file, I know which file to include. If they are split into files with the same name, I know which to include. But, if they're put into files according to "general concern", I have to grep a lot to find the right concern. I think I'd like to trade the searching with longer include lists. Any other opinions? |
|
I think I found a good split but also like get comments / opinions. I think there should be a split (maybe the lines are not yet optimal), i would also like to keep the "kernel_defines.h" like a collection header. And not force a transition to the split includes. But there are cases where you should not include "kernel_defines.h" but a subset is OK. From my POV
Details(it also does not fit into modules version or container) |
|
I searched github wher a define of the name might be: it can be found in util.h, libs.h and obviously most often it is uses to torture gcc. |
benpicco
left a comment
There was a problem hiding this comment.
Looks good to me and kernel_defines.h include still gets the application all defines.
Contribution description
this splits kernel defines by its concerns to ease the use of its parts
Testing procedure
read
Issues/PRs references