[Development] Qt 6 buildsystem support requirements

Jason Newton nevion at gmail.com
Thu Aug 2 20:00:27 CEST 2018


On Thu, Aug 2, 2018 at 9:34 AM Matthew Woehlke <mwoehlke.floss at gmail.com> wrote:
>
> On 2018-08-02 09:03, Oswald Buddenhagen wrote:
> > On Wed, Aug 01, 2018 at 10:33:43AM -0400, Matthew Woehlke wrote:
> >> On 2018-08-01 04:24, Jason Newton wrote:
> >>> On Mon, Jul 30, 2018 at 1:30 PM Matthew Woehlke wrote:
> >>>> Persistent build server? Java? No, thanks.
> >>>
> >>> This is an option, you can keep it in a preference file, or you can
> >>> use it as a command line switch to not use this.
> >>
> >> ...and how many naïve users that "just want to build Qt" are going to
> >> know about that?
> >>
> > and why exactly would a user who doesn't care ... care?
>
> ...because building Qt just spawned a process that is never going to
> terminate, is going to sit around pointlessly monitoring their file
> system, and is going to potentially cause who-knows-what issues?
>
> If I want to just download and build some package (i.e. I'm not
> *actively developing* that software), doing so shouldn't "infect" my
> machine with zombie processes. When the build is done, it should be *done*.

This is arguing over defaults and for a hypothetical case.  The daemon
exits automatically after a preference-set threshold of time of idle.
 It was engineered and tested for many years to not have problems as
to what you are describing, such as updates to the bazel installation
itself, but it is possible something goes wrong .  The capability
makes sense to everyday developers so the it earns it's place in the
world.  There's a flag to opt out and projects can set defaults that
bazel will respect.  Users can also disable it permanently in their
home preference files and invoke bazel with the switch to disable.  If
that is not sufficient, upstream may listen to behavioral changes such
as opt-out by default and opt-in with flags.


>
> > it's not that i *like* big dependencies, but there is a trade-off to be
> > made, and bazel is *by far* the most advanced build tool on the market
> > today when it comes to optimizing rebuilds of massive projects
>
> ...which is *totally irrelevant* to everyone that is not a Qt developer.
> Just like software is written once and read many times, it is developed
> by a few and deployed by many. Optimizing for development *at the
> expense* of deployment strikes me as... questionable. If the penalty to
> deployment cost was minimal, that would be one thing, but with bazel, it
> isn't.

Perhaps there are strategies to make it reduced by stripping out
things in packages and not depending on a full JRE.  Without swing,
some people have reported getting JRE's down to 10 MiB.  I'll remind
again it depends on a JRE, not a JDK - there's some semblance to
arguing about python usage, in that case.

-Jason



More information about the Development mailing list