"make clean" doesn't clean a lot of generated files #23449
Comments
|
This is probably due to us not using BYPRODUCTS when we should. If a script generates a file, and we don't tell CMake about it, then CMake won't know that it should delete it. Until all cases are fixed, users can consider using "make pristine", but note that this deletes the Makefile as well, which is not always desired. |
|
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
|
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
|
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
|
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time. |
|
@tejlmand do you think this is worth pursuing? Maybe documenting the limitations might be another option. |
Yes. It is always worth to ensure that byproducts (and dependencies) are set up correctly everywhere in the build syste. I have briefly looked into this, and the most tricky part is the autogenerated files where we don't know which files are being generated by the scripts, and hence hard to cleanup using byproducts, but from CMake 3.15 there is a new flag that can be used for directories that hold such generated files. The biggest part of this is going manually through the code to find all occurrences, so trade off between effort and gain means this has been low on prioritization list with regards to severity. |
Fixes: zephyrproject-rtos#23449 This commit adds additional OUTPUT and BYPRODUCTS to custom command and targets in the Zephyr build system. This ensures that files produced during the build will be removed again when invoking ninja clean / make clean. The generated syscalls headers include folder is added to the syscall target using ADDITIONAL_CLEAN_FILES property. However, this property is new in CMake 3.15, so will not work when using older CMake with ninja. For CMake versions <=3.15 the ADDITIONAL_MAKE_CLEAN_FILES property is used. However, this only supports Makefile generator. Signed-off-by: Torsten Rasmussen <[email protected]>
|
@carlescufi made a first round here: #32140 |
Fixes: #23449 This commit adds additional OUTPUT and BYPRODUCTS to custom command and targets in the Zephyr build system. This ensures that files produced during the build will be removed again when invoking ninja clean / make clean. The generated syscalls headers include folder is added to the syscall target using ADDITIONAL_CLEAN_FILES property. However, this property is new in CMake 3.15, so will not work when using older CMake with ninja. For CMake versions <=3.15 the ADDITIONAL_MAKE_CLEAN_FILES property is used. However, this only supports Makefile generator. Signed-off-by: Torsten Rasmussen <[email protected]>
Fixes: #23449 This commit adds additional OUTPUT and BYPRODUCTS to custom command and targets in the Zephyr build system. This ensures that files produced during the build will be removed again when invoking ninja clean / make clean. The generated syscalls headers include folder is added to the syscall target using ADDITIONAL_CLEAN_FILES property. However, this property is new in CMake 3.15, so will not work when using older CMake with ninja. For CMake versions <=3.15 the ADDITIONAL_MAKE_CLEAN_FILES property is used. However, this only supports Makefile generator. Signed-off-by: Torsten Rasmussen <[email protected]>
Fixes: #23449 This commit adds additional OUTPUT and BYPRODUCTS to custom command and targets in the Zephyr build system. This ensures that files produced during the build will be removed again when invoking ninja clean / make clean. The generated syscalls headers include folder is added to the syscall target using ADDITIONAL_CLEAN_FILES property. However, this property is new in CMake 3.15, so will not work when using older CMake with ninja. For CMake versions <=3.15 the ADDITIONAL_MAKE_CLEAN_FILES property is used. However, this only supports Makefile generator. Signed-off-by: Torsten Rasmussen <[email protected]>
Fixes: zephyrproject-rtos#33512 The ${ZEPHYR_FINAL_EXECUTABLE}.map file is being renamed at a later stage. The renamed, and thus missing file, causes ninja to relink the target in order to re-create the map file, which then again is renamed. This is fixed by removing the ${ZEPHYR_FINAL_EXECUTABLE}.map as a byproduct and only has the byproduct on the renamed file to ensure proper cleanup, see: zephyrproject-rtos#23449. Signed-off-by: Torsten Rasmussen <[email protected]>
Fixes: #33512 The ${ZEPHYR_FINAL_EXECUTABLE}.map file is being renamed at a later stage. The renamed, and thus missing file, causes ninja to relink the target in order to re-create the map file, which then again is renamed. This is fixed by removing the ${ZEPHYR_FINAL_EXECUTABLE}.map as a byproduct and only has the byproduct on the renamed file to ensure proper cleanup, see: #23449. Signed-off-by: Torsten Rasmussen <[email protected]>
Steps to reproduce:
I would not expect to see generated files still remaining, for example:
Found when debugging #23429 which makes the problem worse for reasons not yet clear to me.
The text was updated successfully, but these errors were encountered: