Hello, I am the upstream developer of QEverCloud library. Sorry for the interference, I'd just like to clarify a bit what QEverCloudGenerator is and how it is intended to work.
Let me start from a brief description of how Thrift IDL - interface definition language - works. It is a pseudo-programming-language "optimized" for the definition of interfaces for structures and functions. There's a tool called thrift compiler which can generate the source code in various actually existing programming languages from the definition in the form of Thrift IDL files. The entire thrift project is currently maintained by the Apache Software Foundation - https://thrift.apache.org. Apache's thrift compiler can produce the C++ source code from Thrift IDL files. However, the resulting C++ code is quite inconvenient to use along with Qt framework due to having to use non-Qt data types along with Qt data types - it results in having to do numerous conversions between these data types which adds to runtime overhead and overall complexity. QEverCloudGenerator is an ad-hoc tool meant to replace the thrift compiler for the particular case of Evernote Thrift IDL files, to generate more Qt-friendly C++ code i.e. the code using Qt data types where possible/feasible. The key word is "ad-hoc". It was not developed to become another backend of the official thrift compiler which is a much more complex task than solving a particular use case of generating some code from a few particular Thrift IDL files using only a subset of allowed Thrift IDL constructs. As such, QEverCloudGenerator can't be considered a general purpose Thrift compiler generating the Qt-friendly C++ code. Evernote people have recently released the Thrift IDL files for the new version of their API - https://github.com/evernote/evernote-thrift/pull/6. Currently QEverCloudGenerator cannot handle the updated Thrift IDL files as the subset of allowed Thrift IDL constructs has been extended compared to the previous version of API. I am in the process of making it able to handle these new files. And unless QEverCloudGenerator becomes the general purpose thrift compiler backend some day, the necessity for the similar procedures should generally be expected to for future Evernote API releases. Regards, Dmitry Ivanov. On Thu, 8 Sep 2016 06:36:48 +0800 Boyuan Yang <073p...@gmail.com> wrote: > 2016-09-08 0:52 GMT+08:00 Sean Whitton <spwhit...@spwhitton.name>: > > The issue is that then we then have multiple copies of the thrift files > > in Debian: a copy in each source package that needs them, either for > > regeneration or in debian/missing-sources/. > > > > Suppose there is an Evernote protocol change, or some other bug that > > means the thrift files get updated. If there is one copy of them in > > Debian, we just update that, and then binNMU all the packages that use > > it, and we're done. > > Unfortunately things will not be the case, at least not for Evernote thrift > files. > > I had some discussions to the current maintainer of QEverCloud about > the possibility of updating thrift IDL files and regenerate again. > https://github.com/d1vanov/QEverCloud/issues/5 > > He just told me it is not possible, since the generator needs to be > updated. Update in Evernote thrift files will simply leads to FTBFS > without the update in the generator. > > > Otherwise, if there are lots of copies, we have to update each package > > separately. That's significantly more work, and can't be done by just > > one person, but needs the involvement of the maintainers of all those > > packages. > > > > This is especially relevant if we need to update the thrift files in a > > Debian stable release: updates to packages in a released version of > > Debian have to go through a careful vetting procedure, and this means we > > only have to do that once. That saves a lot of time (and indeed makes > > it feasible at all). > > > > It's possible I've misunderstood the purpose of the thrift files, though > > -- if there was an Evernote API change, they would have to change and > > the corresponding language-specific generators re-run, right? > > In this specific case, we also need to notice the slow evolvement of > Evernote Cloud API (>= 3 years, longer than Debian stable release cycle. > Take a look at Evernote official SDK) > and the backward compatibility of the API. Not updating API will not cause > problems, and it is the author of program (i.e., nixnote2 author) who has > the responsibility to update the level of API itself uses. Even if the Evernote > API is updated according to the new thrift files by packagers, the added methods > will not be utilized until the program author decide to switch to the > new API, and > the changed/removed methods may lead to FTBFS. > > >> Is there really any previous example in Debian, that one package > >> *should* and *do* Build-Depend on another *binary* package that only > >> contains some description files or source codes? > > > > I'm not sure about a package that only contains source code alone, but I > > can give you an example of one that contains source code plus some other > > stuff: dh-elpa. If you look in the emacsen-common folder of its source > > package, you'll find some scripts. Those get copied into every elpa-* > > binary package (with the package name substituted in). And dh-elpa is > > added to the elpa-* package's Built-Using field. > > > > Before dh-elpa, there was a copy of those emacsen-common scripts in > > every single Emacs lisp addon package (and in package that have not yet
