-
Notifications
You must be signed in to change notification settings - Fork 7.3k
CMakeLists.txt: -fmacro-prefix-map=${CMAKE_SOURCE_DIR}=CMAKE_SOURCE_DIR #16536
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CMakeLists.txt: -fmacro-prefix-map=${CMAKE_SOURCE_DIR}=CMAKE_SOURCE_DIR #16536
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this create aliasing issues between ZEPHYR_BASE and the app dir?
Could -fmacro-prefix-map=${CMAKE_SOURCE_DIR}=app resolve this?
Can you be more specific?
Why not. |
For instance, Zephyr has the file zephyr/include/init.h. Imagine that a user has a different file located at app_dir/include/init.h. Then after pre-processing, the path would look like ./include/init.h. Now imagine that, for whatever reason, some tooling needs to be able to deduce whether this is referencing the zephyr or app init.h. It would not be able to, a human would also be confused, but should at least eventually be able to figure it out. EDIT: If we introduce =app, I suppose we should introduce =zephyr as well to be consistent. |
Thanks @SebastianBoe, makes sense. I'll just wait a couple days to give people a chance to bikeshed the prefix names Shooting first: |
ZEPHYR_BASE? |
If we go for ZEPHYR_BASE then CMAKE_HOME_DIRECTORY would be the corresponding name for the app. |
I think you meant CMAKE_SOURCE_DIR? https://cmake.org/cmake/help/latest/variable/CMAKE_HOME_DIRECTORY.html
Not like this would be "using it in project code" for real but it would still be a bad example (I had never heard of CMAKE_HOME_DIR until now) |
Right, CMAKE_SOURCE_DIR would be better. |
Random question, but what about zephyr modules? That doesn't seem to be covered in this PR (no problem, incremental progress is good!), but I'm curious what ought to be done while we are thinking about this.
|
Very good and not so random question. I haven't observed any module actually triggering any difference for me yet but I guess a list of Note this is (at least) the second issue caused by moving modules higher than ZEPHYR_BASE, here's another, cmake one I've been working on: https://cmake.org/pipermail/cmake/2019-June/069547.html Don't get me wrong: nesting git repositories is horrible so I'm not even thinking about that. Maybe a new WEST_TOP gradually replacing ZEPHYR_BASE? I think it's been mentioned in unrelated context(s). Just thinking out loud. |
In commit 28a5657 we stopped ZEPHYR_BASE from leaking into __FILE__ and other macros. This works great for apps inside ZEPHYR_BASE but does nothing for apps outside ZEPHYR_BASE. -fmacro-prefix-map=${CMAKE_SOURCE_DIR}=CMAKE_SOURCE_DIR does it. To avoid collisions and for consistency change: -fmacro-prefix-map=${ZEPHYR_BASE}=. to: -fmacro-prefix-map=${ZEPHYR_BASE}=ZEPHYR_BASE Quickest test/demo: - Copy samples/hello_word/ to ~/home_world/ - Add "%s", __FILE__ to printf in ~/home_world/src/main.c cmake -B build -S ~/home_world/ -DBOARD=qemu_x86 make -C build run Before: ~/home_world/src/main.c says Hello World! qemu_x86 After: CMAKE_SOURCE_DIR/src/main.c says Hello World! qemu_x86 objdump -h $(find build -name *.c.obj) | grep noinit 9 .noinit."ZEPHYR_BASE/kernel/system_work_q.c".0 0000 17 .noinit."ZEPHYR_BASE/kernel/init.c".2 00000100 000 18 .noinit."ZEPHYR_BASE/kernel/init.c".1 00000400 000 19 .noinit."ZEPHYR_BASE/kernel/init.c".3 00000800 000 16 .noinit."ZEPHYR_BASE/kernel/mailbox.c".2 00000348 18 .noinit."ZEPHYR_BASE/kernel/mailbox.c".1 00000028 20 .noinit."ZEPHYR_BASE/kernel/pipes.c".2 00000280 00 22 .noinit."ZEPHYR_BASE/kernel/pipes.c".1 00000028 00 Signed-off-by: Marc Herbert <[email protected]>
4371d20
to
135afcc
Compare
I want to reach for that too, but we need a solution that works without assuming west, for those easterners out there ;). |
https://app.shippable.com/github/zephyrproject-rtos/zephyr/runs/43105/5/console 2h time out, stuck at
4 other Shippable shards PASS |
Famous last words.
Any ASSERT in a module should reproduce Quick and dirty hack below, moving on for now... bigger fish to fry.
|
Non-urgent ping? 2 lines, 5 approvers :-) |
TA-DA! zephyrproject-rtos/west#311 |
cmake: -fmacro-prefix-map=${WEST_TOPDIR}=WEST_TOPDIR #19440 |
In commit 28a5657 we stopped ZEPHYR_BASE from leaking into
__FILE__ and other macros. This works great for apps inside ZEPHYR_BASE
but does nothing for apps outside ZEPHYR_BASE.
-fmacro-prefix-map=${CMAKE_SOURCE_DIR}=CMAKE_SOURCE_DIR does it.
To avoid collisions and for consistency change:
-fmacro-prefix-map=${ZEPHYR_BASE}=.
to:
-fmacro-prefix-map=${ZEPHYR_BASE}=ZEPHYR_BASE
Quickest test/demo:
cmake -B build -S ~/home_world/ -DBOARD=qemu_x86
make -C build run
Before:
~/home_world/src/main.c says Hello World! qemu_x86
After:
CMAKE_SOURCE_DIR/src/main.c says Hello World! qemu_x86
objdump -h $(find build -name *.c.obj) | grep noinit
9 .noinit."ZEPHYR_BASE/kernel/system_work_q.c".0 0000
17 .noinit."ZEPHYR_BASE/kernel/init.c".2 00000100 000
18 .noinit."ZEPHYR_BASE/kernel/init.c".1 00000400 000
19 .noinit."ZEPHYR_BASE/kernel/init.c".3 00000800 000
16 .noinit."ZEPHYR_BASE/kernel/mailbox.c".2 00000348
18 .noinit."ZEPHYR_BASE/kernel/mailbox.c".1 00000028
20 .noinit."ZEPHYR_BASE/kernel/pipes.c".2 00000280 00
22 .noinit."ZEPHYR_BASE/kernel/pipes.c".1 00000028 00
Signed-off-by: Marc Herbert [email protected]