DTS include dependencies #9724
-
As part of my Meson build I am generating a DTB from a DTS which can of course include other .dtsi files. Because the device tree compiler does not natively support #include, I have a meson custom target where I run the c pre processor before passing this file to the the device tree compiler. My pre processing step has a dependency on the root DTS file, but knows nothing about the included .dtsi files. Does any one have a suggestion on how to resolve this? Currently if one of the included .dtsi files changes, it does not trigger a rebuild. My initial thought was to instruct the c pre processor to generate a .d file where all the dependencies would be listed. With this I could use the fs module to read and create a file list. Unfortunately, I am unable to use the fs read() method in the build tree:
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Why do you need to generate a file list? The fs module runs during the configure stage, before the .d file is created, which is why it is not permitted to read files in the build tree. But, the point of .d file dependencies is for dynamic detection of rebuild dependencies, so the intended way to handle this would be for the .d file to be emitted to the Meson would then record this in the build.ninja as a dynamic runtime dependency file list, and ninja would absorb and then delete the depfile as soon as it is created. |
Beta Was this translation helpful? Give feedback.
-
Sounds like I don't need to 😄. I was originally thinking I needed to in order to use the |
Beta Was this translation helpful? Give feedback.
Why do you need to generate a file list? The fs module runs during the configure stage, before the .d file is created, which is why it is not permitted to read files in the build tree. But, the point of .d file dependencies is for dynamic detection of rebuild dependencies, so the intended way to handle this would be for the .d file to be emitted to the
depfile
kwarg of e.g. custom_target.Meson would then record this in the build.ninja as a dynamic runtime dependency file list, and ninja would absorb and then delete the depfile as soon as it is created.