Closed Bug 740804 Opened 13 years ago Closed 10 years ago

Deploy latest version of GNU make on all build machines

Categories

(Infrastructure & Operations Graveyard :: CIDuty, task, P3)

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: joey, Unassigned)

Details

(Whiteboard: [puppet])

Latest version is v3.82: http://ftp.gnu.org/gnu/make/ Build machines are using a mix of version >= 3.81. One of my try jobs reported variant make function behavior on a single platform (fedora/b2g). Trying to determine if this may be the culprit. cmd version gathering: https://tbpl.mozilla.org/?tree=Try&rev=25b462d2d947 =================================================== try-android-bm09-try1-build2458.txt.gz GNU Make 3.81 try-android-debug-bm27-try1-build1210.txt.gz GNU Make 3.81 try-android-xul-bm27-try1-build1147.txt.gz GNU Make 3.81 try-b2g-bm14-try1-build165.txt.gz GNU Make 3.82 try-linux64-bm27-try1-build908.txt.gz GNU Make 3.81 try-linux-bm27-try1-build1297.txt.gz GNU Make 3.81 try-linux-debug-bm27-try1-build1294.txt.gz GNU Make 3.81 try-macosx64-bm09-try1-build8022.txt.gz GNU Make 3.81 try-macosx64-debug-bm09-try1-build7551.txt.gz GNU Make 3.81 try-macosx-debug-bm09-try1-build8594.txt.gz GNU Make 3.81 try-win32-bm14-try1-build3845.txt.gz GNU Make 3.81.90 try-win32-debug-bm14-try1-build3426.txt.gz GNU Make 3.81.90
make v3.82 is able to report a problem where a recursively expanded macro referenced its-self across circular/nested user function calls. 3.81 +/- will silently accept the problem.
Priority: -- → P3
Whiteboard: [puppet][opsi]
Joey: any change in the version of make we should be targeting after 15 months? Has anything in the intervening time rendered this moot?
Flags: needinfo?(joey)
Whiteboard: [puppet][opsi] → [puppet]
Product: mozilla.org → Release Engineering
It probably would still be beneficial to upgrade make from 3.81 -> 3.82. A quick perusal of the change log between 3.81 -> 3.82 mentions fixes for: buffer overrun, *alloc() changes, implicit rule sorting, win64 addresses and several windows specific fixes around headers and string compare functions: * misc.c (concat): Fix buffer overrun. * implicit.c (stemlen_compare): Fix qsort() compare bug that caused implicit rules with equal stem lengths to be sorted indeterminately. * main.c (handle_runtime_exceptions): Use %p to print addresses, to DTRT on both 32-bit and 64-bit hosts. Savannah bug #27809. (int w32_kill): Use pid_t for process ID argument. * w32/subproc/sub_proc.c: Include stdint.h. (sub_process_t): Use intptr_t for file handles and pid_t for process ID. (process_pipes, process_init_fd, process_begin): Use intptr_t for file handles and pid_t for process ID. Fixes Savannah bug #27809. * job.c (w32_kill, start_job_command, create_batch_file): Use pid_t for process IDs and intptr_t for the 1st arg of _open_osfhandle. * misc.c (strncasecmp): Local implementation for systems without. * config.h.W32.template (HAVE_STRNICMP): Define on Windows. * configure.in: Check for strncasecmp/strncmpi/strnicmp. * job.c [WINDOWS32]: Don't define dup2 on Windows. (pid2str): Use "%Id" even with MSVC (exec_command): Cast to pid_t when calling pid2str(). * w32/subproc/sub_proc.c [WINDOWS32]: Include config.h first. Use stddef.h on MSVC to get intptr_t. * w32/subproc/misc.c [WINDOWS32]: Include config.h first. * w32/compat/dirent.c [WINDOWS32]: Include config.h first. (readdir): Cast -1 to correct type for d_ino. * w32/pathstuff.c [WINDOWS32]: Ensure make.h is included first. * make.h [WINDOWS32]: Don't prototype alloca() on Windows. Add configuration for strncasecmp(). * main.c (ADD_SIG) [WINDOWS32]: Avoid warnings in MSVC. * config.h.W32.template [WINDOWS32]: Don't warn on unsafe functions or variables. * NMakefile.template [WINDOWS32]: Remove /MACHINE:I386. * main.c (clean_jobserver): Cast due to MSVC brokenness. (decode_switches): Ditto. * vpath.c (construct_vpath_list): Ditto. * rule.c (freerule): Ditto. * ar.c (ar_glob): Ditto.
Flags: needinfo?(joey)
Do we still care about this since we use pymake?
Flags: needinfo?(joey)
Flags: needinfo?(coop)
(In reply to Ben Hearsum [:bhearsum] from comment #4) > Do we still care about this since we use pymake? I'll have to check what the current state is. A newer version was released (3.99-4.0?) that corrected problems with make -j on windows and provided a workaround for a few inherent pymake performance problems. Just not sure how ready for prime time the new version is.
Flags: needinfo?(joey)
Flags: needinfo?(joey)
We can lower the priority here, but I think it's still worth standardizing on a single version.
Flags: needinfo?(coop)
We don't care about this bug (much). We do care about bug 927672 a lot because that will make Windows builds significantly faster in automation.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(joey)
https://bugzilla.mozilla.org/show_bug.cgi?id=927213 https://bugzilla.mozilla.org/show_bug.cgi?id=927671 >> It's a goal to make this happen this quarter. This bug should be kept open so make
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
[...] kept open so make can be brought up to a consistent version c#6
Seems like we're happy with where we're at.
Status: REOPENED → RESOLVED
Closed: 11 years ago10 years ago
Resolution: --- → WONTFIX
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.