Op 17/10/2017 om 17:31 schreef Oswald Buddenhagen: > On Tue, Oct 17, 2017 at 05:23:17PM +0200, Ulf Hermann wrote: >>>> Exactly. The halting problem can be worked around pragmatically. >>> ... at the price of getting different build results based on CPU speed ... >>> >>> Your fast desktop CPU crunches through the JS and you get a working >>> built, while my sucky laptop CPU does not and the build fails for me. >> A simple timeout may be a bit too pragmatic, but you could count the >> JS instructions executed. >> > you guys are discussing the locks of a house without walls. when any > type of reasonable limiter needs to kick in, the your build system is > *broken*. that's a fatal error, not just a "different result", and you > need to rethink what you're doing. Could you clear up what you mean *exactly* here? Do you mean 1) that any system that provides some kind of timeout (in terms of wall time or another measure) for evaluation is broken, or that 2) a build setup that runs into such a timeout is broken? That's a big difference.
_I_ think that doing 1) is reasonable to keep a IDE like Creator responsive. And of course, you report an error and fail the build when that happens. A message stating where the issue occured would of course be very helpfull. André _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
