Opened 14 months ago
Closed 14 months ago
#19028 closed enhancement (fixed)
mozilla: drop ./mach configure ?
Reported by: | Owned by: | Douglas R. Reno | |
---|---|---|---|
Priority: | normal | Milestone: | 12.1 |
Component: | BOOK | Version: | git |
Severity: | normal | Keywords: | |
Cc: |
Description
I found the './mach configure' command at Arch, and when looking at newer versions it seemed a good idea to use it to get some confidence that a build I was leaving to run would probably be ok.
With ff-121.0 and python-3.12.1 that is not the case - the configure script ends with non-zero and complains that python-3.12.1 is not supported and I should use 3.11.
No idea what changed in ff121, or else python-3.12.1, to cause that change, looking at ff120.0 mach was also looking for python <= 3.10 but did not complain.
If I go straight into './mach build' the configure is run without problems and the build completes.
With python-3.12.1 './mach install' completes but then gives similar error messages and ends with non-zero status.
Looking at the first candidate for ff-122.0b1 mach still wants python <= 3.11.
If we remove the './mach configure' it doesn't buy us a lot now that the fixes are already present, but maybe we should anyway remove it ?
Change History (5)
comment:1 by , 14 months ago
comment:2 by , 14 months ago
I built TB today without ./mach configure and it built fine. On the particular system I did that, I had not updated to Python-3.12 so I did not need to use $PYTHON311.
comment:3 by , 14 months ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 14 months ago
I'm now testing Seamonkey real quick, but we know TB and Firefox are good so if Seamonkey finishes as expected I will proceed with removing './mach configure' from the trio of Mozilla packages
comment:5 by , 14 months ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I think dropping ./mach configure is probably the best approach since it doesn't seem to be needed. It could be useful for major updates though (for example, going to the next major ESR), but at the same time './mach build' should exit with a non-zero error code if configure fails