[Development] Future of QBS

[Adam Treat]

A few points:

* Unless you are worried about building software with possibly infinite 
dependencies, infinite build products, then a non-Turing complete 
language that just lacks general recursion will be sufficiently 
expressive to meet your needs. In particular, this means those vaguely 
worrying about "sufficiently complex" build systems can rest assured. If 
a strongly normalizing language can suffice as the internal language to 
build a new foundation for ZFC set theory, then I think it'd be 
sufficient to express a deterministic build system.

* Of course you can work around the halting problem so that Qt Creator 
(or some other IDE) doesn't hang should a build never halt. The point of 
non-Turing complete language is that you could ensure this by design.

That said, I think the Turing-completeness question and halting problem 
should be low on the list of priorities for qbs.

Cheers,
Adam

On 10/17/2017 01:16 PM, André Somers 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development