740804 - Deploy latest version of GNU make on all build machines

Status: RESOLVED WONTFIX

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

Description

[Joey Armstrong [:joey]]

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

Comment 1

[Joey Armstrong [:joey]]

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.

Comment 2

[Chris Cooper [:coop] (he/him)]

Joey: any change in the version of make we should be targeting after 15 months? Has anything in the intervening time rendered this moot?

Comment 3

[Joey Armstrong [:joey]]

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.

Comment 4

[[e-mail] (:bhearsum)]

Do we still care about this since we use pymake?

Comment 5

[Joey Armstrong [:joey]]

(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.

Comment 6

[Chris Cooper [:coop] (he/him)]

We can lower the priority here, but I think it's still worth standardizing on a single version.

Comment 7

[Gregory Szorc [:gps]]

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.

Comment 8

[Joey Armstrong [: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

Comment 9

[Joey Armstrong [:joey]]

[...] kept open so make can be brought up to a consistent version c#6

Comment 10

[[e-mail] (:bhearsum)]

Seems like we're happy with where we're at.