[Interest] Oops! Somebody's got a bad case of dependency bloat!

[André Pönitz]

On Wed, Apr 10, 2013 at 12:02:09PM -0700, Thiago Macieira wrote:
> On quarta-feira, 10 de abril de 2013 11.55.24, Bob Hood wrote:
> > No doubt you meant what you said.  However, it hardly changes the fact that
> > the one omitted is rather ubiquitous, regardless of your personal feelings
> > about it.  I have no love for Microsoft (especially after Windows 8), and I
> > hate Apple and their ecosystem snobbery with a passion.  However, as a
> > commercial developer, I understand the need to support them as part of basic
> > business practices.  While I may curse them like a sailor privately, I
> > never allow my prejudices to reach my customers through my product.
> 
> Actually, it's pure statistics.
> 
> Operating systems where Qt current is known to run:
> 
> 	Windows
> 	Mac OS X
> 	Linux
> 	*BSD
> 	Solaris
> 	QNX
> 
> The majority of those have Perl.
> 
> And really, I installed ActivePerl on my IT-locked-down-and-virus-scanning 
> laptop easily. I *really* do not understand what the big deal is -- was my 
> experience atypical?

I'd say so.

Especially on Windows, anything that doesn't come "batteries included"
_is_ a pain. Any dependency reduces the size of the audience.

> If you want to build a hugely complex framework like Qt, with a million lines 
> of code, please understand you'll need to get a beefy machine and install some 
> dependencies. If you don't want to build, try using one of the pre-built 
> binaries.

There is a broad middle ground between "using one pre-built configuration"
and "doing all on your own", and I'd wager a bet that this middle ground is
that what most semi-serious-to-serious Qt-on-Windows users used (and liked
to use) so far.

> Let me give you another important point:
> 
> we're trying to make the source releases to be as close as the repositories on 
> which we (Qt developers) develop Qt. Why? Here are a few reasons:

To be honest and blunt, I see the word "we" used a bit too often for my
liking when it comes to this kind of communication. There are quite a few
of these results that are far from being uncontested within the active
contributors to the Qt Project. I would even consider some "historical
accidents", not conscious decisions. (Did anyone ever _want_ Ruby as build
dependency for, say, Creator?)

>  * we expect that most people who build Qt from sources are Qt developers 
>     themselves (majority of users will download binaries and the stats prove 
>     it);

All "serious" Qt-on-Windows uses I've seen in the past did not use the
standard configuration. The normal situation was that one or two compile
flags were "wrong", and that a couple of patches needed to be applied
locally. While using Perl there would have been acceptable it'd not have
been considered "nice".

Qt has always been about convenience, making a developer's life easier.
Adding build dependencies goes the opposite direction. 
["Developer" as in "people who develop _with_ Qt"]

>  * we want to reduce the need of testing of the source releases by 
>    "leveraging" the testing that is done daily by developers (that is, if the 
>    source releases are substantially different from the repositories, the fact 
>    that dozens of people compile Qt daily proves nothing);

We could run a poll on how many people build Qt on Windows _daily_ for
development purposes, "dozen_s_" is beyond what I can easily imagine ;-}

>  * we want the source packages to have cryptographic verifiability that they 
>     weren't tampered with, by having the sources match *exactly* the 
>     repository, which is already cryptographically verifiable.

I wouldn't accept that as a valid reason. If I wanted to make sure I have
untampered sources, I'd probably pull from gitorios/gerrit, even with the
comfy feeling of seeing an ssh://... somewhere. That incidentally would
also allow for easier handling of those patches on top of Qt.

> I understand this makes some people's lives a bit (or a lot) harder.

Indeed. 

> I understand Christian's concern of managing a farm of computers (by the
> way, don't you have a centralised software deployment solution?)
> 
> I'm just hoping that you guys understand that the changes are done for
> good reasons, they aren't done without forethought. And that Perl has
> been an industry standard for 3 decades.

We (and I mean "we" here) should keep in mind that the validity of
technical (and political) reasons tends to be temporary.

This thread here contains valuable feedback. People are not completely
happy. There seems to be room for improvement. I could e.g. imagine online
installers providing a bit more than "bare bone sources and one prebuilt
configuration" in the medium term.

Andre'