1 Commits (cee9a6669bdf59cfeb7cfefd42af954d418461ca)

Author	SHA1	Message	Date
Guillem Jover	358c3965a6	MT#61993 build: Rework to use a config.mk generated during the build ... These are potentially computed from inside each subdir, and in addition due to what appears to be a regression in GNU make 4.4, where it is reevaluating variables that contain $(shell) functions, many times (in the order of thousands, this was slowing down the build, were on the Debian amd64 build daemons it went from 5m with GNU make 4.3 to 2h40m with GNU make 4.4. Although the bulk of the slow down has been fixed with previous commits, the remaining optimizations are only to avoid this potentially happening again in the future, and to reduce useless duplicate work. Instead of trying to cache the values from within make itself, where programming this there is extremely painful, and does not seem to be able to greatly reduce the number of calls, because the build system is going to be called multiple times for different targets. Simply externalize the generation into several shell scripts, that we call to generate a make fragment that then we include from the various Makefiles. For a Debian build with GNU make 4.3, this reduces the amount of total pkg-config calls from around ~1600 to 128, for dpkg-buildflags from ~1100 down to 6, and for dpkg-parsechangelog from ~56 to 17, but the slow down is not as significant there anyway. For a Debian build with GNU make 4.4, this reduces the amount of total pkg-config calls from around ~2600 to 128, for dpkg-buildflags from ~2800 down to 6, and for dpkg-parsechangelog from ~350 to 21. For a Debian build with GNU make 4.4, this reduces the build time on this system from 2m10s to ~ 1m30s. Change-Id: I427d0ea5106dc6ed1ff9e664ccdba2fa0725b7d0 (cherry picked from commit 7dbe24e4e5)	11 months ago