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

Reviews

See the guideline for information on the review process.

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

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:

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

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 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:

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

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:

Backported to 30.x in #34689.