Opened 4 days ago
Last modified 12 hours ago
#1746 new enhancement
RFE: Allow skip deleting the build directory in chapter 8 with a configuration entry
| Reported by: | xry111 | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | jhalfs | Version: | GIT |
| Severity: | normal | Keywords: | |
| Cc: |
Description
When we get a test failure, retaining the build directory can help us to root cause it.
Change History (4)
comment:1 by , 4 days ago
| Type: | defect → enhancement |
|---|
comment:2 by , 3 days ago
comment:3 by , 2 days ago
For LFS I'm not sure this is useful. The build and test logs are retained and it really would not be hard to just unpack and manually redo the commands one at a time. If there is a problem before Chapter 8 then care needs to be taken for duplicate builds (binutis, gcc, util-linux, etc). I do most of the LFS updates and I do check with jhalfs before most commits (and ALL stable releases) so a user really should not need this type of capability.
I don't use jhalfs for BLFS, but I do retain the build directories. For a relatively complete BLFS I build in a separate partition /build. Right now it is 183G. That does not include texlive.
comment:4 by , 12 hours ago
Ouch, there is a maximum of 32 parameters to xsltproc, and the new one reaches the limit...
Sure, should be easily doable. But as I understand, this would leave all build directories on the system, which represents quite an amount of disk space (not sure how much actually). Maybe it would be better to keep the build directory only on test failure? (run tests with set +e, test $? after running tests, and only if non zero keep the directory). Some packages with expected tests failures would be spuriously kept anyway.
Another option could be to stop the build at the first test failure allowing to rerun the tests immediately), but then there should be a way to inhibit stopping if tests failures are expected...