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

Thiago Macieira thiago.macieira at intel.com
Wed Apr 10 21:14:06 CEST 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130410/037a05a9/attachment.sig>


More information about the Interest mailing list