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

Wed Apr 10 22:27:43 CEST 2013

Hi,

first of all:
I thought this topic is just seen important just by some few commercial devs -
and I'm really surprised by Thiago's replies - which lead to some loss of his
reputation in my mind.

Ok, now I know he's just working for less of half the years with Qt / on
different
platforms like me :-P  ;-)  ;-)

...but serious: Even if I originally came from Microsoft environments (DOS +
Windows)
and chose Linux as my productive development environment over one decade ago,
I *MUST* work with Windows (like Thiago) to support our customer's
Windows-environments.

But I learned to be less missionary and biased concerning the Linux agains
Windows topic.
Maybe you should argument a little bit less biases to not offend your loyal
Windows customers.

Windows can be nearly as powerful as Linux, if you have the right tools (and
enough
money to buy them) ;-)

And yes: There are (mostly bigger / older) companies who have very strict
restrictions
what is allowed to run and which filesystem access is allowed - simply because
of
security restrictions and because of global deployment environments like
NetInstall.

Our customers (where some devs work) have > 14.000 clients and just a handful
admins.
So each client having special installs or special access rights must be
maintained
by these few people - so maybe you can imagine how the react on your last
statements
"just allow it" and "just do it" ;-)

We face the same problems deploying out Qt apps to such big customers -
there we especially face the problems of installing / deploying the VC++
runtimes etc.

I dislike Windows for the problems around the "DLL hell", the not clean OS
architecture
and the many performance and security problems we face with it every day.

BUT: I love Windows in cases when I just need to exec an app or install some
drivers -
that is just a few clicks away and works even beween different Windows versions.
(Imagine you want to deploy a Linux app build on Debian 6 to a RedHat or
openSuSE
distro - even with the same kernel it fails in most cases! Or much more
complicated:
Just try to deploy a driver for a special camera or scanning device - thats
"Mission impossible"!)

So if I read here that the Perl is just needed to create some docs, which ARE
NOT
as security relevant as the sources, I really can't see the arguments agains
shipping
them pregenerated as done in Qt 4.

Are you really trying to convince a senior dev and commercial customer that he
has to change all of his dev environments and the ones of ohers (customers using
his
libs for example) just because you want to save some kilobytes and want to
cryptographically verify just a few HTML doc files? Honestly?

Do you have an idea how difficult and time / support consuming it is to change
internal and external (customer) development environments?

Sorry, but I currently don't know if I have to laugh or cry about this... I'm
really missing
some hard objective facts which prevent continuing with shipping out the
pregenerated
docs like in Qt 4 before.

And as side notice:
Migrating an industrial grade application framework from one toolkit or
compiler/SDK
version (e.g. Qt 4 + VS 2008) to a newer one (Qt 5 + VS 2010) takes up to a
year!
The rollout to all customers than can take one or more years after that!

That's the background many commercial devs have to concern and that's the
reason why I (and surely) many other commercial customers where happy
about the less ABI and dependency changes of Qt within the last seven years
(only Qt 4.3 - 4.5 was a little bit problematic).

So who is responsible for this descision and who is the one to talk to?

Best Regards,
Christian

> On 10. April 2013 at 21:14 Thiago Macieira <thiago.macieira at intel.com> wrote:
>
>
> On quarta-feira, 10 de abril de 2013 10.28.52, Cyrus Harrison wrote:
> > Hi Everyone,
> >
> > Q: Is perl needed for both the headers & documentation?
> >
> > If the documentation was included three times in previous source
> > releases, couldn't that issue be resolved or maybe the
> > documentationcould be omitted if it consumes too much space?
>
> No, Perl is needed for the headers only. The documentation is built by qdoc.
>
> There are two reasons we used to include the documentation pre-built in Qt 4:
>
> 1) a buildsystem quirk, which required Qt to be installed before qdoc3 could
> be run to build the documentation;
>
> 2) so that the HTML documentation was available to you the moment that you
> unpacked the source tarball.
>
> > For those that don't have full reign over their computers (no package
> > manager access, or no admin rights, etc) these issues can be quite
> > frustrating. Perhaps we are the minority, but a `batteries included'
> > approach benefits everyone.
>
> I'm sorry, but if you can't install packages how did you get a compiler
> installed in the first place? And if you're not allowed to install software,
> are you allowed to install Qt?
>
> > Are their any platform customizations applied when generating the headers?
>
> No, they are the same on all platforms.
>
> > If not, for us poor souls, it sounds like one ugly solution would be to
> > steal the headers from one of the binary releases, and copy them into a
> > source release. Not caring about disk space or network traffic issues -
> > that might be easier to automate than becoming a perl caretaker on
> > several types of platforms.
>
> I don't want to do that. I want the source release to be identical to the Qt
> repository. No modifying of the sources.
>
> That buys you traceability: you can cryptographically verify that the sources
> you got match exactly the repository with no modifications, no new files, no
> deletions. In turn, since the repository is cryptographically secure, you can
> verify that all the changes are proper.
>
> > Is there / could there be a target that just generates the headers and
> > creates a new source release package? This would allow folks like us to
> > easily create our own tarball on one platform, and use it on others to
> > avoid the perl dependency. It won't solve everyone build predicament,
> > but it could help and maybe some kind soul could post tarballs for other
> > folks.
>
> Maybe the solution, as someone else pointed out, is to have a *binary* tool to
> replace syncqt.
>
> So the build process on Windows would be:
>
> 1) run configure.bat
> 2) configure.bat compiles configure.exe and runs it
> 3) configure.exe compiles syncqt.exe and runs it
> 4) configure.exe compiles qmake.exe and runs it
>
> Do you understand how hard it is to make Windows work, an OS without even a
> decent shell script interpreter?
>
> > One last comment: Active State Perl comes with different license terms
> > than Qt. Probably not a deal breaker, but it does require legal
> > consideration. I am a huge Qt fan, I am sure the other vocal folks on
> > this list are as well.
> > The take away is: barriers like these - even if they seem quite small -
> > will dampen adoption.
>
> Oh... licensing. Now that's something I had not considered...
>
> Is there anyone with time on their hands and would like to contribute a C++
> replacement for syncqt (the Perl script)?
>
> History trivia: qmake is a C++ replacement of an earlier Perl tool called
> tmake. See http://tmake.sourceforge.net/.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
Mit den besten Grüßen,
Christian Dähn
Consultant

// ASinteg GmbH
// Hagenower Strasse 73, 19061 Schwerin
// Registergericht Schwerin HRB 9035, Geschäftsführer: Sandro Seltitz
// Telefon +49 (0)385 30 200 500, Fax +49 (0)385 30 200 509
// Internet http://www.asinteg.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130410/becca65a/attachment.html>