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

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 15 January 2015 20:31:58 Thiago Macieira wrote:
> 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.

Yes, my bad. I actually spent quite some time to try to correctly phrase this 
paragraph trying to express that I'm not trying to force anything nor generate 
a debate nor bad faith nor... but it seems I failed :-/ Allow me to blame the 
fact that I'm not a native speaker and I live at least 1000km away from the 
nearest english-speaking country ;)
 
> > 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.

We are possibly missing quite a lot of them, but having a list of things to 
look at really helps. Thanks!

> 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?

There's actually one thing we maintainers are allowed to do: recreate the 
original tarball regenerating all the necessary files and then ship that. It's 
a compromise solution, but if we can add those steps directly in the build 
process the better.

> > 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.

Well, a convenience we can't use then.
 
> > 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.

Ah, let's hold on a little here. Up to this point I was *always* referring to 
stuff that gets 100% created after some process, like javascript minification.

Stuff that needs hand editing *is* special, as one could consider it as the 
preferred form of modification. It might be a gray area, but if somebody has 
to fiddle with some data to create the source code then we trust upstream in 
this in the same way we trust for the 100% hand-coded stuff.

> > 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).

*My pleasure*. And thanks *a lot* for pointing those files above. I'll filter 
out those that need manual editing and see what I can do with the rest of 
them.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150116/5153a2ce/attachment.sig>