depends: Allow building Qt packages after interruption #34713

1. 
   hebasto commented at 6:01 pm on March 2, 2026: member

   If a build is interrupted, a standard mkdir command may fail if the directory already exists. Switching to mkdir -p ensures the build can resume gracefully.

   Fix #34712.

2. depends: Allow building Qt packages after interruption 2a7a4f608a
3. hebasto added the label Build system on Mar 2, 2026
4. 
   DrahtBot commented at 6:02 pm on March 2, 2026: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	sedited

   If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

5. DrahtBot added the label CI failed on Mar 2, 2026
6. 
   geovanirodriguez commented at 8:02 pm on March 2, 2026: none

   I took a quick look at the failure mode shown in the issue log. Changing mkdir to mkdir -p does avoid the immediate “File exists” error, but I’m not sure it fully covers the interrupted-build case.

   If the job gets killed while qtbase/qttranslations/qttools/cmake are being populated, those directories can be left half-extracted. On the rerun, mkdir -p will continue without failing, but the build may now proceed using a partially extracted tree, which could later show up as harder-to-trace configure or build errors.

   One possible alternative would be to make the extract step explicitly restart-safe by clearing those directories before re-extracting, for example in both depends/packages/native_qt.mk and depends/packages/qt.mk:

   0$(build_SHA256SUM) -c $($(package)_extract_dir)/.$($(package)_file_name).hash && \
   1rm -rf qtbase qttranslations qttools cmake && \
   2mkdir qtbase && \
   3$(build_TAR) --no-same-owner --strip-components=1 -xf $($(package)_source) -C qtbase && \
   4mkdir qttranslations && \
   5$(build_TAR) --no-same-owner --strip-components=1 -xf $($(package)_source_dir)/$($(package)_qttranslations_file_name) -C qttranslations && \
   6mkdir qttools && \
   7$(build_TAR) --no-same-owner --strip-components=1 -xf $($(package)_source_dir)/$($(package)_qttools_file_name) -C qttools && \
   8mkdir cmake && \
   9cp ...
   

   This does mean a rerun may redo the extraction work, but it guarantees that rerunning make starts from a clean extracted state instead of whatever was left behind after the interruption.

   I tried this locally by interrupting the depends build during extraction and rerunning make, and it resumed cleanly using this approach as well.

7. DrahtBot removed the label CI failed on Mar 3, 2026
8. 
   hebasto commented at 2:17 pm on March 4, 2026: member

   I took a quick look at the failure mode shown in the issue log. Changing mkdir to mkdir -p does avoid the immediate “File exists” error, but I’m not sure it fully covers the interrupted-build case.

   If the job gets killed while qtbase/qttranslations/qttools/cmake are being populated, those directories can be left half-extracted. On the rerun, mkdir -p will continue without failing, but the build may now proceed using a partially extracted tree, which could later show up as harder-to-trace configure or build errors.

   One possible alternative would be to make the extract step explicitly restart-safe by clearing those directories before re-extracting, for example in both depends/packages/native_qt.mk and depends/packages/qt.mk:

   0$(build_SHA256SUM) -c $($(package)_extract_dir)/.$($(package)_file_name).hash && \
   1rm -rf qtbase qttranslations qttools cmake && \
   2mkdir qtbase && \
   3$(build_TAR) --no-same-owner --strip-components=1 -xf $($(package)_source) -C qtbase && \
   4mkdir qttranslations && \
   5$(build_TAR) --no-same-owner --strip-components=1 -xf $($(package)_source_dir)/$($(package)_qttranslations_file_name) -C qttranslations && \
   6mkdir qttools && \
   7$(build_TAR) --no-same-owner --strip-components=1 -xf $($(package)_source_dir)/$($(package)_qttools_file_name) -C qttools && \
   8mkdir cmake && \
   9cp ...
   

   This does mean a rerun may redo the extraction work, but it guarantees that rerunning make starts from a clean extracted state instead of whatever was left behind after the interruption.

   I tried this locally by interrupting the depends build during extraction and rerunning make, and it resumed cleanly using this approach as well.

   I’ll leave the branch as is for now, as it follows the current defaults:https://github.com/bitcoin/bitcoin/blob/01dcb2fcc5834071eb3cc1c1ad2f8c931d80e741/depends/funcs.mk#L125

9. sedited approved
10. 
    sedited commented at 11:14 am on March 5, 2026: contributor

    ACK 2a7a4f608a42acef5cdf7370f0d191119fdb94c9
11. fanquake merged this on Mar 5, 2026
12. fanquake closed this on Mar 5, 2026

    ---

13. hebasto deleted the branch on Mar 5, 2026
14. fanquake referenced this in commit 330a804432 on Mar 5, 2026
15. 
    fanquake commented at 3:45 pm on March 5, 2026: member

    Backported to 30.x in #34689.

Contributors
hebasto DrahtBot geovanirodriguez sedited fanquake

Labels
Build system