bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygnulib] gnulib-python initial merge and some minor bug fixes


From: Dmitry Selyutin
Subject: Re: [pygnulib] gnulib-python initial merge and some minor bug fixes
Date: Mon, 21 Aug 2017 23:49:21 +0300

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" <address@hidden> написал:
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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]