-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Seeking for ways to regenerate src/generated/*
files
#5
Comments
QEverCloud sources are generated from Evernote's Thrift IDL files using the custom code generating parser. The generation happens during the build of that generator, i.e. just do I can foresee that Debian developers would like the generated files be generated during the build of QEverCloud. However, I am actually against it because it would sufficiently complicate the building of QEverCloud (more build-dependencies + more build steps + complication of existing build steps) + Thrift IDL files would typically only change along with Evernote API itself and when that changes, the generated files would most likely have API/ABI breaks compared to previous version making it necessary to do some manual refinement of non-generated QEverCloud sources or at the very least bump the version of the library. Therefore, I really don't think the QEverCloud sources should be treated in the same way as shortened JS files - it's a very different kind of source code generation. |
Thanks, I will take a look. P. S. This is Debian; even though things may become a little bit 在 2016年9月4日週日 17:15,Dmitry Ivanov notifications@github.com 寫道:
|
So there's no chance at all to avoid the generation step during the build of QEverCloud for Debian? Even if my reasoning above is explained to the Debian developer mentoring this packaging project? If so, the Debian's patch to QEverCloud might get veeery complex. |
Thinking of it more, I think the easiest way to work around this rigid Debian policy would be the following:
In addition to this, you'd need to add QEverCloudGenerator as a build dependency to QEverCloud package + add pre-build steps in debian/rules: before even starting to build QEverCloud (i.e. before executing CMake for it) you'd need to execute QEverCloudGenerator on these Thrift IDL files and put the sources/header it would generate to the relevant folders of QEverCloud. Then you could execute the remaining build steps as necessary. The suggested patch in #4 would affect only the Debian package building but not the QEverCloud's own build system which I consider a good thing. In more general sense I still don't think it's of any use to run the generator on the Thrift IDL files during each build as they are not something that changes often or something that anyone except Evernote people would even want to change - serioulsy, it's just an abstract description of their API. Sorry if this suggestion is less than you hoped for but it sounds like too much work for me to handle myself right now. On the bright side, if/when this is over, you'd be quite proficient in packaging hard stuff to Debian 😃 |
Take it easy, things won't be too difficult. I could make QEverCloudGenerator a git submodule of QEverCloud in the debian source package to prevent the emergence of another debian package called I looked through the generator's code and it looks fine. On the first glance, using One more question: could you provide with the copyright status of |
Ok, that way seems simpler, indeed. The generator's sources including those in |
@hosiet, just FYI, Evernote guys are actually slowly update their APIs, see this PR for Thrift IDL files. I've tried to run the existing generator on the updated IDL files, no luck so far due to more complicated data model in their new API - some structs contain exception objects, some exceptions reference structs etc. I'd have to update the generator to handle this new stuff. And such quirks are very likely to occur with the future versions of their API. So "just replacing the Thrift IDL files and regenerating the new sources from them" is likely to not work in the real world. The new API also means I'd have to release another major version of QEverCloud eventually - it would contain a ton of API breaks but since it's Evernote who controls that, the max I can do is to try minimizing the damage by ensuring the two major versions of the library can coexist within a single system. I don't think Evernote people are going to shut down the current API (1.25) any time soon as that would require updating all of their official SDKs (zero done at the moment) + give some time to thirdparty developers for adopting them. |
I see. It seems that the shutdown of the old API will not take place in the near future, so we have some time. The biggest problem may be making FYI, I updated the |
I've taken a look at it. Yeah, it's surely not "cmake && make" thing anymore 😃 Despite my feelings about the policy enforcing this, the work done so far looks impressive. |
Hello,
According to Debian Policy (and REJECT faq), the generated files must be provided together with its original form (and must be guaranteed to be able to be regenerated from the original form), otherwise it needs to be wiped completely from the source code.
Could those files generated from Evernote Thrift API be regenerated in some ways? If possible, could you please provide with an example (e.g., the original source needed and some example shell commands)? That will help make QEverCloud suitable for entering Debian.
Thanks!
The text was updated successfully, but these errors were encountered: