gnulib-tool.py: trivial fixes

2017-09-09 Thread Bruno Haible
Hi Dmitry, Here are some proposed fixes for trivial issues. May I push these? Bruno >From d33ea821528592e87bb85de6059710ccf869 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sat, 9 Sep 2017 00:38:56 +0200 Subject: [PATCH 02/16] gnulib-tool.py: Bump copyright years up to 2017. --- gnuli

gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Bruno Haible
Hi Dmitry, I've started to copy all modifications done to gnulib-tool since 2012 over to gnulib-tool.py. Here is the first round of such updates. OK to push? Most of these are not really tested, and I'm a beginner regarding Python. Therefore it's very possible that you find mistakes in these patc

Re: gnulib-tool.py: trivial fixes

2017-09-09 Thread Dmitry Selyutin
Sure, perfectly OK. 2017-09-09 12:40 GMT+03:00 Bruno Haible : > Hi Dmitry, > > Here are some proposed fixes for trivial issues. May I push these? > > Bruno > > -- With best regards, Dmitry Selyutin

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Dmitry Selyutin
Hi Bruno, I have only one question regarding --no-changelog option. Are you sure you want to entirely deprecate it? Because right now it is a no-op, but parser still doesn't bark when it founds it. The current behavior of gnulib-tool.py matches the same of gnulib-tool. Once you will apply the chan

Re: gnulib-tool.py argument parsing

2017-09-09 Thread Dmitry Selyutin
Hi Bruno, to be honest, the command-line parsing in the gnulib-tool.py certainly sucks. I'm creating a new command-line parser from the scratch, and it works like charm. For example, it is much easier to avoid the error you described. I'll take a look on how to fix the current parser and try to co

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Tim Rühsen
On Samstag, 9. September 2017 13:08:09 CEST Dmitry Selyutin wrote: > Hi Bruno, > > I have only one question regarding --no-changelog option. > Are you sure you want to entirely deprecate it? > Because right now it is a no-op, but parser still doesn't bark when it > founds it. > The current behavio

Re: gnulib-tool.py: trivial fixes

2017-09-09 Thread Bruno Haible
Dmitry Selyutin wrote: > Sure, perfectly OK. OK, I've pushed these.

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Bruno Haible
Hi Dmitry, Thanks for the reviews. > Because right now it is a no-op, but parser still doesn't bark when it > founds it. > The current behavior of gnulib-tool.py matches the same of gnulib-tool. > Once you will apply the change, parser shall complain on unknown > --no-changelog, Good point. I mi

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Bruno Haible
Hello Tim, > So if you remove it from bootstrap, I'll update bootstrap in our project main > dir and that's it. No, we don't remove it from 'bootstrap'. This piece of backward-compatibility code is not expensive to keep. > @Bruno Maybe it would be wise to just have a symlink to gnulib/build-aux

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Eric Blake
On 09/09/2017 09:38 AM, Bruno Haible wrote: > Hello Tim, > >> So if you remove it from bootstrap, I'll update bootstrap in our project >> main >> dir and that's it. > > No, we don't remove it from 'bootstrap'. This piece of backward-compatibility > code is not expensive to keep. > >> @Bruno Ma

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Bruno Haible
Hi Dmitry, Here's the next round of patches, for your review. I'm slowly working through the past gnulib-tool changes. Bruno >From 5aa8b0d419518889a8d6f392c2d38fdd438ce39f Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sat, 9 Sep 2017 12:01:28 +0200 Subject: [PATCH 1/6] gnulib-tool.py: Fix s

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Dmitry Selyutin
Hi Bruno, thanks for these patches. I've left some comments below. > [PATCH 6/6] gnulib-tool.py: follow gnulib-tool changes, part 14 > gnulib-tool: don't transform binary files with sed All these sed transformers shall be IMHO entirely deprecated. I don't quite remember why I used sed; may be I

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Bruno Haible
Hi Dmitry, > > [PATCH 6/6] gnulib-tool.py: follow gnulib-tool changes, part 14 > > gnulib-tool: don't transform binary files with sed > All these sed transformers shall be IMHO entirely deprecated. I don't quite > remember why I used sed Using 'sed' is acceptable here because the input comes from

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Dmitry Selyutin
> Well, the logic that binary files (*.mo, *.class) should be copied as-is, > not transformed, should be kept, no? You'll replace the implementation > of the transform? The binary files shall not be touched, but text files shall not be processed with sed. That's what I mean; the patch is OK, but th

Re: gnulib-tool.py: follow gnulib-tool changes

2017-09-09 Thread Tim Rühsen
On Samstag, 9. September 2017 09:51:01 CEST Eric Blake wrote: > On 09/09/2017 09:38 AM, Bruno Haible wrote: > > Hello Tim, > > > >> So if you remove it from bootstrap, I'll update bootstrap in our project > >> main dir and that's it. > > > > No, we don't remove it from 'bootstrap'. This piece of