Fix relative includes#870
Conversation
I've replaced relative include paths with absolute paths rooted at `src/` or `include/`. This makes your code more robust and easier to understand. I made these changes conservatively, only modifying includes where there was a single, unambiguous match. Note: The build is failing due to a pre-existing issue with a missing system header (`machine/endian.h`). This is unrelated to the changes I just made.
I have replaced relative include paths with absolute paths rooted at `src/` or `include/`. This makes the code more robust and easier to understand. I automated this process, conservatively modifying only the includes where there was a single, unambiguous match. Note: The build is failing due to a pre-existing issue with a missing system header (`machine/endian.h`). This is unrelated to the changes in this commit.
bakerstu
left a comment
bakerstu
left a comment
There was a problem hiding this comment.
I think this is a net positive. Before merging this, we should also remove the -I paths from the various Makefiles that allowed these to build without the "relative" paths in the first place. That will prevent future regression and ensure we didn't miss anything.
|
@balazsracz can you check the stm32 build, it looks like it may be related to the include shuffle and something missing in libify.sh. |
I fully agree on the cleanup of the -I paths but I believe that it will still compile either way due to how GCC handles |
3 participants
Replaces all relative include paths with absolute directory includes.
Exceptions: