Hi Bruno, what do you think if I'll periodically merge stable versions into the master? For example, I think currently the imported 'as is' version can be merged. I'd like to work on API on a separate branch though, since I roughly dislike the idea of developing on master.
For example, see my latest commit; even though it does not affect the API yet, these classes (and similar stuff) are going to replace all this mess with setters and getters, and when it will begin to happen, I don't want to break the current gnulib-tool.py (even though it is considered to be experimental yet). P.S. I've just started doing the very same thing around Config class that I had done five years ago, but previously it had taken approximately 1000 lines more than now. Wow, just wow. 21 авг. 2017 г. 11:36 ПП пользователь "Bruno Haible" <br...@clisp.org> написал: Hi Dmitry, > The development is going to happen inside a standalone branch. > Once stuff becomes mature enough, it'll be pushed into the master. I would like to make it easy for users to invoke gnulib-tool.py for users, without changing their autogen.sh / bootstrap / Makefile.devel /... scripts or recipes. I'll do this by introducing an environment variable, say, GNULIB_TOOL_PYTHON so that people can do $ GNULIB_TOOL_PYTHON=yes ./autogen.sh instead of $ ./autogen.sh This will be a couple of lines of code in gnulib-tool, to invoke gnulib-tool.py with the same arguments. The prerequisite for this is only that gnulib-tool.py is properly invokable through python or python3, and that it sits in the 'master' branch. It is *not* a requirement that it is "mature enough". Bruno
