rtpengine

Commit Graph

Author	SHA1	Message	Date
Guillem Jover	257a5a9029	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`) (cherry picked from commit `1e1075bf38`)	1 year ago
Guillem Jover	bbf7b2e7b8	MT#61993 build: Force recursive variables into simple ones Starting with GNU make 4.4, build time have massively regressed where before they would take 5m on amd64 now can take 2h40m. While this seems clearly broken, the release notes are filled with notices for breaking changes, and in particular the one for passing all make variables down to the invoked programs executed via the «shell» GNU make function, so it is not clear what is expected breakage and what is not. This has been reported in Debian, but not yet upstream, and while it seems like a clear regression, it's not clear what will be the upstream take on it. For now apply workarounds that do not change semantics, and which do not regress with older GNU make versions. Use the GNU make «origin» function instead of «?=» which defaults to defining a variable as a recursive one. Coerce already defined variables into simple ones to avoid GNU make re-evaluating these variables for each «shell» function invocation. Ref: https://bugs.debian.org/1092051 Change-Id: I076fc05dd616918473a22e7e942fecfdc9851d47 (cherry picked from commit `887fb40f3f`) (cherry picked from commit `67a2b222c7`)	1 year ago
Richard Fuchs	872c06d1cc	MT#55283 add bufferpool implementation Manages a pool of bump allocators that allow re-use of buffers after they become empty Change-Id: Id677a2e18b39c2261b8ceae31056d4ad9125bf2c	2 years ago
Richard Fuchs	32dd03cbd6	MT#54294 update to codec-chain framework Change-Id: Ic6286494fad459df4a77665aae66f1af03e9664b	3 years ago
Richard Fuchs	2fa121c0d9	MT#54294 add GPU support Change-Id: I035eff68a4448ad1b2f5b4520943626e1723fce7	3 years ago
Richard Fuchs	e5cb0018eb	MT#56374 add perf-tester Change-Id: I9863b4e97238dcc6759f21d9685aa101dae75fa1	3 years ago

6 Commits (mr12.5.1.53)