cmake: Add option for exporting build metadata to Make #22020
Conversation
|
An example of a makefile being generated: |
SebastianBoe
added
area: Build System
Feature
|
All checks are passing now. Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages. |
|
@SebastianBoe: I much appreciate your working on this, I'll look into this soon. |
|
Ok, this looks pretty good. Note that in my workarounds I used CMake's So, I was able to put this to work, and this indeed simplifies integration files on 3rd-party app side noticeably. Looking forward to fixes suggested in the comment above, thanks! |
SebastianBoe
force-pushed
the
makefile_exports
branch
from
2d6632c
to
de8ab79
Compare
|
There were some issues with how CMake reads out the build metadata when I tried to create a target, so it will have to be an automatically generated file. Thank you for the feedback @pfalcon , it is now addressed. |
Add an opt-in feature that will generate a Makefile with build variables like CC, and KBUILD_CFLAGS for consumption by third-party Make-based build systems. This emulates the 'outputexports' target that KBuild supported and is supported for the same reasons that KBuild supported it. Easier integration with third-party build systems. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
SebastianBoe
force-pushed
the
makefile_exports
branch
from
de8ab79
to
5803846
Compare
|
@SebastianBoe, thanks, works great, approved. For reference, example of simplification to 3rd-party build system is here: https://github.com/pfalcon/pycopy/compare/zephyr-new-Makefile.exports . But this change is one half of the story. The 2nd half is examplified by this line: https://github.com/pfalcon/pycopy/compare/zephyr-new-Makefile.exports#diff-35d7a1c676537f5e7dfb8d9ae6926033L111 : This list is quote adhoc and changes over time, causing breakage (which is expected, as those are Zephyr's internal targets). What I would be looking is the analog of the following make rule: Where "genheaders" (or more suitable name, per your likes) would be an official public build system target, causing any autogenerated to be generated (so, after that target, it would be possible to compile an app-level source code featuring I assume that this change would be only simpler than this PR. And the main point of these changes isn't even technical, but "organizational" - to treas these new facilities (Makefile.exports.* generation and "genheaders" target) as parts of "external public interface" of Zephyr build system. So for example, of you (as the maintainer of the build system) do refactors of it, to keep in mind that their functioning/behavior should be preserved. Likewise, if you review changes of other folks to the build system, to consider this point to. And if something if overlooked (we're all humans), leading to regression, then such reports to be produced with a due priority to recover the functionality. I from my side would be glad to look into adding regression tests for this functionality into Zephyr tree (currently, this functionality is used in JerryScript/MicroPython Zephyr ports, for which we run CI on our (Linaro's) side, so I would see any regressions soon. To run regression builds for this functionality as part of Zephyr CI, there's a kind of "organizational" issue of building samples using non-CMake top-level build system). Thanks again! |
Add an opt-in feature that will generate a Makefile with build
variables like CC, and KBUILD_CFLAGS for consumption by third-party
Make-based build systems.
This emulates the 'outputexports' target that KBuild supported and is
supported for the same reasons that KBuild supported it. Easier
integration with third-party build systems.
This fixes #4917