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
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" <***@clisp.org>
Post by Dmitry Selyutin
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
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".