This version supports local generation only. It's intentionally stupid, and does not support any kind of dependency checking. If you run the script, it's going to call SWIG. Period. While this is a slow process, we are going to combine the use of the swig bot with checked in static bindings, meaning that it won't be terribly important to only regenerate the bindings when the input files have actually changed. I'm open to the possibility of adding dep checking, but I want to make sure there's a clear use case for it first. A side benefit of this is that the implementation is drastically simpler. Since depending on how you call the script, swig can be run on either the client or the server, it means both the client and server need to be able to reuse the code that physically exec's swig. This logic is therefore contained in the file `local.py`, which is used by by both `client.py` and (later) `server.py`. This is all experimental at the moment, but it duplicates a lot of the logic currently found in prepare_bindings.py. There was not a good way to reuse some of the logic without invasive changes on that script, and since this script is still experimental, it makes sense to just copy them over, and if / when this becomes more mature, we can get rid of the other ones. One thing that differs fundamentally from previous implementations is that there is no need for a custom `_python.py` version of the script. AFAICT you can generate multiple languages with a single swig invocation so there is no reason to invoke swig multiple times, which is what the old system would do. So this new method just contains logic to build up a single command line which can generate everything at once. The modify step is not included here, because again the idea here is that this will be run on a remote server. So you will eventually do the modify locally after receiving the result from the server.
Details
- Reviewers
tfiala
Diff Detail
Event Timeline
Note: I was wrong in my initial post, you can't actually generate multiple language bindings in a single invocation. So the second patchset loops over the language list and invokes swig multiple times.
Note that we have some occurrences of %pythoncode in the swig files, so languages other than python don't work anyway atm. But I don't want to make it harder than it needs to be for someone in the future to make this work.
Nice, I'm looking forward to looking at this in depth.
I'm out (not around a computer) until after Thanksgiving. I may be a little laggy on feedback.
Basic idea looks fine. (I saw you put this in not long after, but I'm finally getting to look at the actual review).
I'm not sure if you're intending to cover all the use cases of the generation, but I think the prepare_bindings.py will also have swig generate the compiler dependency .d file that some of the compilers will use.