On 2018/05/06 01:08, Brian Callahan wrote: > > > On 5/5/2018 4:47 PM, John Long wrote: > > On Fri, 2018-05-04 at 12:49 -0400, Brian Callahan wrote: > >> On 05/04/18 12:46, Stuart Henderson wrote: > >>> On 2018/05/04 11:09, Brian Callahan wrote: > >>>> On 05/04/18 06:45, Solene Rapenne wrote: > >>>>> Christian Weisgerber writes: > >>>>> > >>>>>> I see this splashed on my dpb window. Apparently a port > >>>>>> writes to > >>>>>> /dev/tty during the build. Any idea which one? > >>>>>> > >>>>>> 476 loops; 25s; 139520 Kstmts; 4894 Kst/sec > >>>>>> 381 loops; 20s; 111675 Kstmts; 4891 Kst/sec > >>>>>> 93 loops; 5s; 27261 Kstmts; 4778 Kst/sec > >>>>> it's lang/snobol4 > >>>>> > >>>> Fix looks like the attached. > >>> Rather than patching build infra to avoid the test, would it be > >>> simpler > >>> to use e.g. /dev/stderr instead of /dev/tty? > >> In this case, I think no. There's no reason to run the tests during > >> the > >> build. It just adds a forced minute of time to every build of > >> snobol4. > >> We can still patch the test to use /dev/stderr instead of /dev/tty > >> of > >> course. > >> > > The guy who wrote SNOBOL4 for *NIX collects timing reports from various > > boxes and OS. So the timing report *can* be somewhat useful. > > > > /jl > > > > Yes I know. I've communicated with upstream and provided timing reports. > My crappy little netbook holds the world record for slowest amd64 > machine he has a report for. > > However, there's no point in having the package build machines run a > timing report each and every time they make new packages. If a user > wants to do it, fine. That's what `make test` is for. > > ~Brian >
It might not be useful to do the timing run as part of a normal build, but this is quite an intrusive patch to carry.. Do you think upstream might accept something like that themselves? With the xsnobol4 target it's clear there is meant to be a way to build without running tests so perhaps it's an oversight that the install target depends on timing.out?
