Collin Funk wrote:
> > The first workaround should fix trouble similar to what we regularly
> > see with 'autom4te.cache': Unnecessary difference while comparing source
> > trees, unnecessary "git status" noise. Clutter.
>
> I don't think the Python stuff should clutter 'git status' atleast.
>
>
On 4/22/24 4:22 AM, Bruno Haible wrote:
> The first workaround should fix trouble similar to what we regularly
> see with 'autom4te.cache': Unnecessary difference while comparing source
> trees, unnecessary "git status" noise. Clutter.
I don't think the Python stuff should clutter 'git status' atl
Thanks for the report, Paul.
Thanks for the preliminary investigation, Collin.
> > ./bootstrap
> > ./configure
> > make -k distclean
> > git submodule foreach git pull origin master
> > git commit -m 'build: update gnulib submodule to latest' gnulib
> > ./bootstrap --no-git --gnulib-sr
Hi Paul,
On 4/22/24 12:56 AM, Paul Eggert wrote:> export GNULIB_TOOL_IMPL=sh+py
> ./bootstrap
> ./configure
> make -k distclean
> git submodule foreach git pull origin master
> git commit -m 'build: update gnulib submodule to latest' gnulib
> ./bootstrap --no-git --gnulib-srcdir=gnul
Thank you very much Bruno and Paul,
I will look into the links.
It is great that gnulib-tool does not use Python packages, but only the
core of Python from its own tarball :-).
Cheers,
Mohammad
On 2024-04-21 03:52, Bruno Haible wrote:
5. Regenerate the fetched and generated files of your package. Depending on
the package, this may be a command such as
$ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
I had a failure with this step when using current GNU diffutils
(3d1a56b906
On 2024-04-21 15:27, Bruno Haible wrote:
ISO C, btw, is also "ever-changing"
Yes, plus if a language is not "ever-changing" it's dead.
The main thing to worry about is when old code stops working not when
new language features get added. Since Python 3 came out Python has been
reasonably goo
[CCing bug-gnulib]
Mohammad Akhlaghi wrote:
> Dear Bruno,
>
> Thanks for sharing the good news about the speed improvement. Gnuastro
> uses Gnulib and it has been very valuable :-).
>
> I had two questions:
>
> 1. Will the shell version of Gnulib-tool continue to be the main version
> for Gnul
Dear Gnulib developers,
Le dimanche 21 avril 2024 à 06:52 -0400, Bruno Haible a écrit :
> If you are developer on a package that uses GNU gnulib as part of its
> build
> system:
I have a very simple personal project using gnulib.
> 1. Make sure you have Python (version 3.7 or newer) installed on
If you are developer on a package that uses GNU gnulib as part of its build
system:
gnulib-tool has been known for being slow for many years. We have listened to
your complaints. A rewrite of gnulib-tool in another programming language
(Python) is ready for beta-testing. It is between 8 times and
10 matches
Mail list logo
