package/nut: workaround parallel build issue
PATCH 1/1 package/nut: workaround parallel build issue
The conditions are not trivial to reproduce, but it can happen that the headers are not fully regenerated by the time they are included.
Since they already are present and current in the archive, just patch out their generation from the Makefile.
Fixes:
http://autobuild.buildroot.org/results/523/5231ff39a0839ec5e1962662004214d4b0773068/ http://autobuild.buildroot.org/results/5a7/5a75d44c028e77b58f0fd9ab794952f2b477dd84/
--- .../nut/0003-tools-do-not-regenerate-headers.patch | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 package/nut/0003-tools-do-not-regenerate-headers.patch
package/nut/0003-tools-do-not-regenerate-headers.patch new file +39 -0
@@ -0,0 +1,39 @@ +From f14e783b3575ccd3db5ca61fddec3ff5a033d530 Mon Sep 17 00:00:00 2001 +From: "Yann E. MORIN" <[email protected]> +Date: Sat, 23 Dec 2017 16:21:27 +0100 +Subject: [PATCH] tools: do not regenerate headers + +This is definitely not parallel-safe, and as the commetns explain, +fixing is not trivial. Since the headers are alreasy correct in the +archive, we just do not regenerate them. + +Signed-off-by: "Yann E. MORIN" <[email protected]> + +--- +Upstream status: not upstreamable. +--- + tools/Makefile.am | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +diff --git a/tools/Makefile.am b/tools/Makefile.am +index 1ba28201..7c144649 100644 +--- a/tools/Makefile.am ++++ b/tools/Makefile.am +@@ -14,13 +14,11 @@ + # Anyway, for the time being, we force build in ./ before nut-scanner, + # to have nutscan-{usb,snmp}.h built before going into the nut-scanner + # sub-directory +-SUBDIRS = . nut-scanner ++SUBDIRS = nut-scanner + + EXTRA_DIST = nut-usbinfo.pl nut-recorder.sh nut-ddl-dump.sh \ + gitlog2changelog.py nut-snmpinfo.py driver-list-format.sh + +-all: nut-scanner-deps +- + # XXX these rules are all bogus! They cause un-named target files to + # always be rebuilt! None of that is ever the right way to use make, + # and especially not Automake. Explicit filenames and their exact +-- +2.11.0 +
Signature · 1 line
2.11.0
PATCH 1/1 package/nut: workaround parallel build issue
Quoted 5 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
The conditions are not trivial to reproduce, but it can happen that the headers are not fully regenerated by the time they are included.
Quoted 8 lines
Since they already are present and current in the archive, just patch out their generation from the
Makefile.Fixes:
http://autobuild.buildroot.org/results/523/5231ff39a0839ec5e1962662004214d4b0773068/ http://autobuild.buildroot.org/results/5a7/5a75d44c028e77b58f0fd9ab794952f2b477dd84/Signed-off-by "Yann E. MORIN" <[email protected]>
Thanks, but doesn't it make more sense to just use MAKE1 instead of such a non-upstreamable patch?
Nut is not a very big package and has no reverse dependencies, so the impact of MAKE1 is quite small.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 package/nut: workaround parallel build issue
On 2017-12-26 19:56 +0100, Peter Korsgaard spake thusly:
Quoted 12 lines
Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
The conditions are not trivial to reproduce, but it can happen that the headers are not fully regenerated by the time they are included.
Since they already are present and current in the archive, just patch out their generation from the
Makefile.Fixes:
http://autobuild.buildroot.org/results/523/5231ff39a0839ec5e1962662004214d4b0773068/ http://autobuild.buildroot.org/results/5a7/5a75d44c028e77b58f0fd9ab794952f2b477dd84/
Quoted 7 lines
Quoted 1 line
Signed-off-by "Yann E. MORIN" <[email protected]>Thanks, but doesn't it make more sense to just use MAKE1 instead of such a non-upstreamable patch?
Nut is not a very big package and has no reverse dependencies, so the impact of MAKE1 is quite small.
I timed a nut build, and indeed the build time for a non-parallel build is split as such (on an otherwise-unloaded machine):
14:18:03 >>> nut 2.7.4 Extracting
14:18:03 >>> nut 2.7.4 Patching
14:18:03 >>> nut 2.7.4 Updating config.sub and config.guess
14:18:03 >>> nut 2.7.4 Configuring
14:18:03 >>> nut 2.7.4 Autoreconfiguring
14:18:10 >>> nut 2.7.4 Patching libtool
14:18:15 >>> nut 2.7.4 Building
14:18:37 >>> nut 2.7.4 Installing to targetSo it is about 34s, of which 22s to build, while a parallel build would take just about 8s to build.
I'll send a patch to use MAKE1.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 package/nut: workaround parallel build issue
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Yann" == Yann E MORIN <[email protected]> writes:
Hi,
Quoted 15 lines
Quoted 2 lines
Nut is not a very big package and has no reverse dependencies, so the impact of MAKE1 is quite small.
I timed a nut build, and indeed the build time for a non-parallel build is split as such (on an otherwise-unloaded machine):
14:18:03 >>> nut 2.7.4 Extracting 14:18:03 >>> nut 2.7.4 Patching 14:18:03 >>> nut 2.7.4 Updating config.sub and config.guess 14:18:03 >>> nut 2.7.4 Configuring 14:18:03 >>> nut 2.7.4 Autoreconfiguring 14:18:10 >>> nut 2.7.4 Patching libtool 14:18:15 >>> nut 2.7.4 Building 14:18:37 >>> nut 2.7.4 Installing to target
Quoted 4 lines
So it is about 34s, of which 22s to build, while a parallel build would take just about 8s to build.
I'll send a patch to use MAKE1.
Great, thanks!
Signature · 1 line
Bye, Peter Korsgaard