On Thu, Aug 2, 2018 at 9:34 AM Matthew Woehlke <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
