[Development] Adding new third party component three.js to Qt?

[Thiago Macieira]

On Friday 16 January 2015 00:54:31 Lisandro Damián Nicanor Pérez Meyer wrote:
> > We do that for other sources that seldomly change, like the outputs from
> > qlalr. We also ship generated docs and the generated include/ headers.
> > That's for ease of building, not for hiding anything. Remember we have
> > trouble even asking for Perl to be present during build.
> 
> Before answering this one please note that I understand why you do this and
> why you would prefer to keep doing it. It happens that distros like Debian
> (and for what I read, also Fedora) think differently.

I think you need to get some leeway and not think in absolute terms.

> I realize we in Debian might be missing to regenerate some stuff (maybe
> quite a lot) but when we find stuff that has been pre-generated we do our
> best to re generate it during the build process.

Do you remove and regenerate:
 - the Unicode tables in qunicodedata.cpp?
 - the CLDR data in qlocale_data_p.h and qtimezoneprivate_data_p.h? How about 
   the locale list in qlocale.h?
 - the indexed string tables in qdbuserror.cpp, qbenchmarkperfevents.cpp, 
   qxmlstream.cpp, and qsimd.cpp?
 - the QML parser from qmljs.g? 
 - the XML parser from qxmlstream.g? (note the cyclic dependency, since qlalr 
   depends on QtCore)
 - the pre-generated IAccessible2 interfaces (Windows-only, think of cross-
   mingw)
 - the class list in tools/uic/ui4.h?

And this is just qtbase. I'm sure there are more.

Doesn't it suffice to know that you can regenerate the generated code? Even the 
ones you can regenerate perfectly, down to the same indentation?

> Doc is an example, we Debian maintainers need to ensure that every piece we
> ship is in it's preferred form of modification and that we are able to
> create the resulting stuff ourselves with the tools in the archive. So
> pregenerated doc is not a solution for us.

I'm not saying it was a solution. I'm saying it is a convenience.

> Anyone: if you find something that needs regenerating and we (again, Debian)
> are not doing it, do not hesitate to fill a serious bug in Debian's bug
> tracker. Or ping me if you somehow find it and you are not using Debian.

See above. Most of it requires manual editing to insert the resulting output 
back into the source code.

> If there is a free tool which can be used instead of the non-free one we
> will do our best to use it, even if the result is sub-par. Else we would
> prefer to simply remove the offending file and tell our users "sorry, but
> it needs a non-free tool to build". Putting Qt in the contrib repo is a
> much worst user disservice than not shipping the file (and again, in Debian
> terms).

Thanks for the info. We all agree we don't want that to happen. That's why 
we're discussing now, so we can find a solution that works for the packagers, 
like we did in the past for qtchooser (a solution designed for distro's 
needs).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center