Re: gnulib-tool: Apply libgnu.{, l}a specific CFLAGS to all its object files

> 2025-02-03 Bruno Haible > > gnulib-tool: Apply libgnu.{,l}a specific CFLAGS to all its object files. Oops, this change broke the --create-testdir option. How to reproduce: $ ./gnulib-tool --create-testdir --dir=../testdir1 --with-c++-tests --without-privileged-tests

Re: gnulib-tool: Allow compiler warnings in Gnulib code

Collin Funk wrote: > I've updated the gnulib-tool-tests in the maint-tools repository with > the output of gnulib-tool.py [1]. Thanks. That is helpful. Bruno

Re: gnulib-tool: Allow compiler warnings in Gnulib code

s in lib/. Thanks, this looks good to me since some projects like using -Werror for their own code. I've updated the gnulib-tool-tests in the maint-tools repository with the output of gnulib-tool.py [1]. Collin [1] https://git.savannah.gnu.org/cgit/gnulib/mai

gnulib-tool: Allow compiler warnings in Gnulib code

INTER' not handled in switch [-Werror=switch-enum] lib/vasnprintf.c:6510:21: error: enumeration value 'TYPE_COUNT_INT_FAST64_T_POINTER' not handled in switch [-Werror=switch-enum] cc1: all warnings being treated as errors make[2]: *** [Makefile:20334: lib/libcoreutils_

gnulib-tool: Apply libgnu.{, l}a specific CFLAGS to all its object files

This patch fixes a long-standing bug in gnulib-tool: Library-specific CPPFLAGS and CFLAGS, i.e. libgnu_a_CPPFLAGS and libgnu_a_CFLAGS, would only apply to object files declared through lib_SOURCES += foobar.c but not to object files declared through AC_LIBOBJ([foobar]) For the latter, the

Support several gnulib-tool invocations better

Gnulib supports multiple gnulib-tool invocations in the scope of the same configure.ac since 2021 (cf. 2021-04-11, 2021-04-17, 2021-06-13). Namely, the module indicator variable (@GNULIB_@) expand to something that depends on the gnulib-tool invocation. This is still not working right with some

Re: gnulib-tool --po-base - allow empty message catalog

his is useless noise > for them. My understanding is that packages do not provide these files to translators and that the translations are updated from Gnulib translations by gnulib-import. For these reasons, a new method was designed and is now recommended. If you pass the ‘--po-base=DIREC

Re: gnulib-tool --po-base - allow empty message catalog

[CCing bug-gettext] Hi Gavin, Gavin Smith wrote in : > ... I found that the file was supposed to be updated by > "make texinfo_tp-gnulib.pot-update". This ran xgettext which is one > of the gettext programs to handle message f

gnulib-tool --po-base - allow empty message catalog

In the Texinfo project, I was updating the version number and regenerating translations. We are now using the translations for Gnulib code that are updated automatically when gnulib-tool runs. However, I found that the version number in the translation files in one of the Gnulib imports was not

gnulib-tool: Fix description of --lgpl option (missed on 2021-06-04)

On 2021-06-04, gnulib-tool stopped doing license template replacements in the source files. gnulib-tool's --help message was not updated at that time. This patch does it now. 2024-08-29 Bruno Haible gnulib-tool: Fix description of --lgpl option (missed on 2021-

Re: gnulib-tool shell vs. Python

to run the shell-based one. Either you have the environment variable GNULIB_TOOL_IMPL set. Unset it. It is not documented, and its purpose is fulfilled. Or you should have gotten a warning: gnulib-tool: warning: python3 not found or too old, using the slow shell-based implementation Bruno

Re: gnulib-tool-tests: Add tests for --extract-dependents.

Collin Funk wrote: > I pushed two test cases for 'gnulib-tool --extract-dependents' to > gnulib/maint-tools.git so I can validate any changes I make [1]. Thanks. I added them to the 'test-all.sh' script. Bruno

gnulib-tool-tests: Add tests for --extract-dependents.

I pushed two test cases for 'gnulib-tool --extract-dependents' to gnulib/maint-tools.git so I can validate any changes I make [1]. I'll probably hold off on 'gnulib-tool --extract-recursive-dependents' until I can get a faster version working. I rather keep 'in

gnulib-tool: Omit the logs of skipped tests from test-suite.log

Automake < 1.17. It makes use of a new feature in Automake 1.17 [1]. [1] https://lists.gnu.org/archive/html/bug-automake/2024-06/msg3.html 2024-07-22 Bruno Haible gnulib-tool: Omit the logs of skipped tests from test-suite.log. * gnulib-tool.sh (func_emit_tests_Makefile

bootstrap: Avoid failure when gnulib-tool removed gettext.m4

t status: 1 ./bootstrap: autoreconf failed The problem is that gnulib-tool removes gettext.m4. Since the autoreconf invocation at the end must not call autopoint (because that could install .m4 files that are older than the gnulib ones), we must invoke autopoint + gnulib-tool again, a

Re: We can not run gnulib-tool in the MinGW.

On Sat, Jul 6, 2024 at 12:40 PM Bruno Haible wrote: > > Paul Eggert wrote: > > > are we OK to drop the ability to run gnulib-tool on Solaris 10? > > > > I'm OK with it. When I deal with Solaris 10 (hey, our department's admin > > server is still Solaris

Re: We can not run gnulib-tool in the MinGW.

me@DOOR UCRT64 /e/workspace/github.com/gnu/gnulib $ ./gnulib-tool --find sys/ioctl.h gnulib-tool: warning: file sys/ioctl.h does not exist me@DOOR UCRT64 /e/workspace/github.com/gnu/gnulib $ ./gnulib-tool --find ioctl gnulib-tool: warning: file ioctl does not exist me@DOOR UCRT64 /e/workspace

Re: We can not run gnulib-tool in the MinGW.

ried this command, but >> > sigprocmask still is not recognized. >> > [image: image.png] >> >> The image tells me that you want to port GNU readline to native Windows. >> >> If you were attempting to port some other package to native Windows, I >> would

Re: We can not run gnulib-tool in the MinGW.

work, I also tried this command, but > > sigprocmask still is not recognized. > > [image: image.png] > > The image tells me that you want to port GNU readline to native Windows. > > If you were attempting to port some other package to native Windows, I > would recommend to

Re: We can not run gnulib-tool in the MinGW.

ckage to native Windows, I would recommend to read the gnulib manual's chapter "Invoking gnulib-tool". But GNU readline is special: it relies heavily on the behaviour of Unix ttys, as specified by POSIX. Native Windows does not implement Unix ttys, and Gnulib does not either. Ther

Re: We can not run gnulib-tool in the MinGW.

the goal is to create some sort of library that you can reuse, gnulib-tool isn't set up for that directly. It is a source-code library only. If you want to create an object-code library you must do it yourself, following the instructions in the manual (or looking at other examples of how it&

Re: We can not run gnulib-tool in the MinGW.

anlex N wrote: > my prefix=/e/workspace/github.com/gnu/gnulib/my-gnulib/me/build/make/built, > make install do not work. https://www.gnu.org/software/gnulib/manual/html_node/Building-gnulib.html does not say that "make install" does anything useful in this situation. What are you trying to do? W

Re: We can not run gnulib-tool in the MinGW.

; > INSTALL_DATA='${INSTALL} -m 644' > INSTALL_PROGRAM='${INSTALL}' > INSTALL_SCRIPT='${INSTALL}' > INSTALL_STRIP_PROGRAM='$(install_sh) -c -s' > INT32_MAX_LT_INTMAX_MAX='' > INT64_MAX_EQ_LONG_MAX='' > LC_COLLATE_IMP

Re: ssh into Solaris 10 [was: We can not run gnulib-tool in the MinGW.]

Hi Paul, Paul Eggert writes: > Don't know what OpenSSH version you normally run, but with > OpenSSH_9.6p1 this configuration works for me: > > Host cfarm210 > HostName %h.cfarm.net > HostKeyAlgorithms +ssh-rsa > PubkeyAcceptedAlgorithms +ssh-rsa > RequiredRSASize

ssh into Solaris 10 [was: We can not run gnulib-tool in the MinGW.]

On 7/6/24 23:52, Collin Funk wrote: I can't even ssh into the compile farm Solaris 10 machine without compiling a custom ssh client: $ ssh cfarm210.cfarm.net Bad server host key: Invalid key length Don't know what OpenSSH version you normally run, but with OpenSSH_9.6p1 this configu

Re: We can not run gnulib-tool in the MinGW.

Bruno Haible writes: > Paul Eggert wrote: >> >> I'm OK with it. When I deal with Solaris 10 (hey, our department's admin >> server is still Solaris 10 sparc!) I run gnulib-tool elsewhere and copy >> the results to Solaris 10. Does anybody do otherw

Re: We can not run gnulib-tool in the MinGW.

Paul Eggert wrote: > > are we OK to drop the ability to run gnulib-tool on Solaris 10? > > I'm OK with it. When I deal with Solaris 10 (hey, our department's admin > server is still Solaris 10 sparc!) I run gnulib-tool elsewhere and copy > the results to Solaris 1

Re: We can not run gnulib-tool in the MinGW.

On 7/6/24 17:07, Bruno Haible wrote: are we OK to drop the ability to run gnulib-tool on Solaris 10? I'm OK with it. When I deal with Solaris 10 (hey, our department's admin server is still Solaris 10 sparc!) I run gnulib-tool elsewhere and copy the results to Solaris 10. Does

Re: We can not run gnulib-tool in the MinGW.

ead of computing and using the absolute file name. The test suite still passes: $ cd maint-tools/gnulib-tool-tests; ./test-all.sh But are we OK to drop the ability to run gnulib-tool on Solaris 10? The % operator used in the variable expansion ${progname%/*} is not supported by Solaris 10 /bin/sh, see

Re: We can not run gnulib-tool in the MinGW.

win even after we get rid of the shell implementation of gnulib-tool. I installed the attached to do that.From 15ec89beae6ded70d4079c5c49861d0b701a353b Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 6 Jul 2024 16:41:44 +0200 Subject: [PATCH] gnulib-tool: simplify/speed startup * gnulib

Re: We can not run gnulib-tool in the MinGW.

; PACKAGE_URL='' PACKAGE_VERSION='0' PATH_SEPARATOR=':' PRAGMA_COLUMNS='' PRAGMA_SYSTEM_HEADER='' PRIPTR_PREFIX='' PTRDIFF_T_SUFFIX='' RANLIB='' REPLACE_ABORT='' REPLACE_ACCESS='' REPLACE_ALIGNED_

Re: We can not run gnulib-tool in the MinGW.

ry, > but also of all the ancestor directories of that directory. I don't think this is a permission issue. That error is expected when passed a directory that already exists: $ ./gnulib-tool --create-testdir --dir=/tmp/my-testdir terminfo If the option passed to '--dir' ex

Re: We can not run gnulib-tool in the MinGW.

anlex N wrote: > After install DEPENDENCIES in the gnulib source code, it can run: Good! > But only /tmp folder can be run, or “not overwriting destination directory” > error still occurs, why? Permission problems on Windows are hard to understand: The permissions depend not only on the owner an

Re: We can not run gnulib-tool in the MinGW.

After install DEPENDENCIES in the gnulib source code, it can run: hello@world UCRT64 /e/workspace/github.com/gnu/gnulib $ ./gnulib-tool --create-testdir --dir=/tmp/my-testdir terminfo Module list with included dependencies (indented): absolute-header alignasof alignasof-tests

Re: We can not run gnulib-tool in the MinGW.

anlex N wrote: > patching file build-aux/test-driver > /e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** could not patch > test-driver script > /e/workspace/github.com/gnu/gnulib/gnulib-tool.py: *** Stop. I would guess that you don't have a 'patch' program in your PATH. Try $ type patch $

Re: We can not run gnulib-tool in the MinGW.

On 7/4/24 14:08, anlex N wrote: I follow Paul Eggert's steps: me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib $ sh -x ./gnulib-tool --create-testdir --dir=/tmp/testdirr --verbose terminfo Oh, I meant for you to run sh -x ./gnulib-tool --list as I thought you said that even a s

Re: We can not run gnulib-tool in the MinGW.

I follow Paul Eggert's steps: me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib $ sh -x ./gnulib-tool --create-testdir --dir=/tmp/testdirr --verbose terminfo + progname=./gnulib-tool + func_gnulib_dir + case "$progname" in ++ pwd + self_abspathname=/e/workspace/github.com/gnu/

Re: We can not run gnulib-tool in the MinGW.

> me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib > > $ ./gnulib-tool --list > > > > I run this command in the gnulib source code, but have no output, why? > > In the past, I had problems compiling Rufus on MinGW, even though > Rufus specifically said to use MinGW. &g

Re: We can not run gnulib-tool in the MinGW.

Hello Simon, the problem is not like you say. so sad. On Thu, Jul 4, 2024 at 4:26 PM Simon Josefsson wrote: > anlex N writes: > > > me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib > > $ ./gnulib-tool --list > > > > I run this command in the gnulib source

Re: We can not run gnulib-tool in the MinGW.

On 7/4/24 09:17, Collin Funk wrote: As long as a Python version ≥ 3.7 is installed everything should be fine on that end: Yes, though sometimes Python is misinstalled. When I run "sh -x ./gnulib-tool --list", the last thing it does is: exec /home/eggert/src/gnu/gnulib/./gnulib-tool

Re: We can not run gnulib-tool in the MinGW.

Hi Collin, > It could be possible that MinGW is missing required programs to run. Please be careful about the term. We need to distinguish * mingw - which is a toolchain (set of runtime libraries, together with a customized GCC) from * the development environments that people use.

Re: We can not run gnulib-tool in the MinGW.

On Wed, Jul 3, 2024 at 11:27 PM anlex N wrote: > > me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib > $ ./gnulib-tool --list > > I run this command in the gnulib source code, but have no output, why? In the past, I had problems compiling Rufus on MinGW, even though Rufus speci

Re: We can not run gnulib-tool in the MinGW.

anlex N writes: > me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib > $ ./gnulib-tool --list > > I run this command in the gnulib source code, but have no output, why? Could this be EOL character problem? In one of my .gitlab-ci.yml files I have needed to add this:

Re: We can not run gnulib-tool in the MinGW.

Paul Eggert writes: > My guess is that you don't have Python installed, or it's installed > but is missing some crucial component. If you have some expertise in > MinGW - or learn it better, which would be a good idea if you really > want to use gnulib-tool under MinGW

Re: We can not run gnulib-tool in the MinGW.

? Paul. On Thu, Jul 4, 2024 at 3:29 PM Paul Eggert wrote: > On 7/4/24 04:26, anlex N wrote: > > me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib > > $ ./gnulib-tool --list > > > > I run this command in the gnulib source code, but have no output, why? > > My gu

Re: We can not run gnulib-tool in the MinGW.

On 7/4/24 04:26, anlex N wrote: me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib $ ./gnulib-tool --list I run this command in the gnulib source code, but have no output, why? My guess is that you don't have Python installed, or it's installed but is missing some crucial compone

Re: We can not run gnulib-tool in the MinGW.

me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib $ ./gnulib-tool --list I run this command in the gnulib source code, but have no output, why? me@DESKTOP UCRT64 /e/workspace/github.com/gnu/gnulib $ ./gnulib-tool --create-testdir --dir=tmp/testdir terminfo E:/workspace/github.com/gnu/gnulib

Re: We can not run gnulib-tool in the MinGW.

ftware/gnulib/manual/gnulib.html>. I can not run > gnulib-tool in the MinGW. > > please see the detail in this dicord > <https://discord.com/channels/792780131906617355/1257539661434327132> > > How to solve? Hi. Please include the details in your bug report, logging in

We can not run gnulib-tool in the MinGW.

Hello Teacher! I value your feedback very much Nice to meet you. My name is anlex N <https://github.com/anlexN>. I am a verified google maintainer of popular open source projects. I am reviewing gnulib <https://www.gnu.org/software/gnulib/manual/gnulib.html>. I can not run gnulib

Re: gnulib-tool Python tracebacks after control-C

Collin Funk wrote: > Ah, interesting. I think in English it would mostly depend on the > context. "Interruption" means you are stopping something from > progressing, but I don't think the word itself describes if it is > temporary or not. "Stop" more strongly indicates a permanent halting > of the

Re: gnulib-tool Python tracebacks after control-C

t. I'm fine with "*** Stop.", but anyone can change it if they would like. I modified the previous diff a bit. Since cli_exception is just an exception hook, I think it makes the code less awkward to catch the KeyboardInterrupt separately in another "except ..." line in main()

Re: gnulib-tool Python tracebacks after control-C

Collin Funk wrote: > executing aclocal -I glm4 > ^C/home/collin/.local/src/gnulib/gnulib-tool.py: *** Stop. > $ echo $? > 1 > > Is that similar to what you were thinking of? I'm not sure what to put > for the error message. Feel free to commit something if this works for you. Yes, that's what I m

Re: gnulib-tool Python tracebacks after control-C

On 5/15/24 8:45 PM, Bruno Haible wrote: > Can you make gnulib-tool.py print a diagnostic in this case as well? > It does not need to be exactly "caught signal SIGINT", like bash does. > Just an indication that > - gnulib-tool.py > - is being terminated > - due to a signal 2. > Preferrably for

Re: gnulib-tool Python tracebacks after control-C

Hi Collin, > $ gnulib-tool --create-testdir --dir testdir1 > ^C > $ It does not print any diagnostic. While gnulib-tool.sh and subprocesses do print a diagnostic: $ rm -rf ../testdir1; ./gnulib-tool.sh --create-testdir --dir=../testdir1 --single-configure stdbit-h Module

Re: gnulib-tool Python tracebacks after control-C

e help. $ gnulib-tool --create-testdir --dir testdir1 ^C $ CollinFrom 43ca9607f03b697df0dfc356ef1a3029551c9897 Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Wed, 15 May 2024 20:25:38 -0700 Subject: [PATCH] gnulib-tool.py: Don't print tracebacks when Ctrl-C is pressed. MIME-V

Re: gnulib-tool Python tracebacks after control-C

Note that also handles a closed stdin (and stdout elsewhere in that util). Interesting. Nice work. I see you dealt with the Python 2 compatability stuff in 'file_is_closed'. :) Thanks for the idea. I'll have a look at adding it to gnulib-tool later today or tomorrow. Collin

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

Collin Funk wrote: > I've committed the attached patch. Looks good. Thanks. Bruno

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

On 5/14/24 2:24 AM, Bruno Haible wrote: > But the first line of this diagnostic looks strange, without an > indication where it comes from. Recall our conventions: > - For an error during option handling, prepend the absolute program name. > - For an error due to the contents of some files, pre

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

On 5/14/24 7:54 AM, Paul Eggert wrote: > I am still falling back on the shell implementation when I discover > gnulib-tool.py bugs or issues, and that's still happening to me (as recently > as yesterday). So Collin, if it's not too much trouble, please update > gnulib-tool.sh for this mkdir issu

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

On 2024-05-14 02:24, Bruno Haible wrote: I can do the same in gnulib-tool.sh if you would like since it should be pretty easy there too. This is not needed. The Python implementation is already the default. We haven't heard from anyone who needs to run the shell implementation. I still need to

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

Collin Funk wrote: > I've applied the attached patch. > ... > $ gnulib-tool --create-testdir --dir foo -h stdbit > not overwriting destination directory: foo > /home/collin/.local/src/gnulib/gnulib-tool.py: *** Stop. Thanks! But the first line of this diagnostic looks

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

exists, since the call is guaranteed to > overwrite configure.ac, Makefile.am, and other files. I've applied the attached patch. I can do the same in gnulib-tool.sh if you would like since it should be pretty easy there too. $ gnulib-tool --create-testdir --dir foo -h stdbit [...] execu

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

Paul Eggert wrote: > Perhaps both implementations should quickly exit in this situation, come > to think of it. I agree. I've made the same mistake a number of times. There is no valid use for continuing if $destdir already exists, since the call is guaranteed to overwrite configure.ac, Makefile.

Re: Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

On 5/13/24 7:45 PM, Paul Eggert wrote: > I messed up. However, the shell implementation of gnulib-tool diagnoses my > mistake right away, before going on its slow way: > > $ GNULIB_TOOL_IMPL=sh ./gnulib-tool --create-testdir --dir foo -h stdbit > mkdir: cannot create direct

Python './gnulib-tool --create-testdir --dir F' should quickly warn if F exists

If I run this command twice, by mistake: ./gnulib-tool --create-testdir --dir foo -h stdbit ./gnulib-tool --create-testdir --dir foo -h stdbit The second invocation eventually fails with: ... executing automake --add-missing --copy patching file build-aux/test-driver /home/eggert/src

Re: gnulib-tool Python tracebacks after control-C

On 13/05/2024 21:48, Collin Funk wrote: Hi Paul, On 5/13/24 9:39 AM, Paul Eggert wrote: I realized that I invoked ' ./gnulib-tool --create-testdir --dir foo stdbit' with the wrong options so I interrupted it with control-C. It then gave me the following long traceback, which is not

Re: gnulib-tool Python tracebacks after control-C

Hi Paul, On 5/13/24 9:39 AM, Paul Eggert wrote: > I realized that I invoked ' ./gnulib-tool --create-testdir --dir foo stdbit' > with the wrong options so I interrupted it with control-C. It then gave me > the following long traceback, which is not useful. I suggest shuttin

gnulib-tool Python tracebacks after control-C

I realized that I invoked ' ./gnulib-tool --create-testdir --dir foo stdbit' with the wrong options so I interrupted it with control-C. It then gave me the following long traceback, which is not useful. I suggest shutting off the Python traceback info after control-C unless perhap

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

Collin Funk wrote: > I've applied the attached patch to fix this crash. Thanks. Looks good. > I'm not sure why gnulib-tool.sh handles the tabs correctly to be > honest... It's because after deps=`func_get_dependencies $module | sed -e "$sed_dependencies_without_conditions"` the variable deps

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

On 5/11/24 12:26 PM, Paul Eggert wrote: > To reproduce it in a Gnulib repository, run these commands: > > git checkout 4de6323d5d20996e51097a90f617cd4404a23eba > ./gnulib-tool --create-testdir --dir foo -h stdbit > > The failing output is as follows. I get this output o

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

On 5/11/24 7:16 PM, Bruno Haible wrote: > Sorry Paul. No. We have been using spaces for indentation and tabulation > since 2009, and the coding got significantly simplified by that. Tabs are > still used in ChangeLog, in Makefile.am snippets (because some 'make' > programs give a syntax error when

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

Paul Eggert wrote: > > Also in Emacs 'whitespace-mode' I noticed the lines that cause issues > > use tabs instead of spaces. Shouldn't that be disallowed? > > I'd allow tabs there, myself. In Gnulib we don't use leading tabs, but > columnar tabs are OK, e.g., in build-aux/gcc-warning.spec. Sorry

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

On 2024-05-11 16:47, Collin Funk wrote: Also in Emacs 'whitespace-mode' I noticed the lines that cause issues use tabs instead of spaces. Shouldn't that be disallowed? I'd allow tabs there, myself. In Gnulib we don't use leading tabs, but columnar tabs are OK, e.g., in build-aux/gcc-warning.sp

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

Hi Paul, On 5/11/24 12:26 PM, Paul Eggert wrote: > git checkout 4de6323d5d20996e51097a90f617cd4404a23eba > ./gnulib-tool --create-testdir --dir foo -h stdbit Also in Emacs 'whitespace-mode' I noticed the lines that cause issues use tabs instead of spaces. Shouldn't that be d

Re: gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

Hi Paul, On 5/11/24 12:26 PM, Paul Eggert wrote: > To reproduce it in a Gnulib repository, run these commands: > > git checkout 4de6323d5d20996e51097a90f617cd4404a23eba > ./gnulib-tool --create-testdir --dir foo -h stdbit > > The failing output is as follows. I get this outpu

gnulib-tool (Python) bug: "module count-one-bits doesn't exist"

I ran into a problem when using gnulib-tool on an earlier version of the new stdbit module. The problem went away when I had GNULIB_TOOL_IMPL=sh in the environment. The gnulib-tool code hasn't changed since the commit in question, so the gnulib-tool bug is presumably still there even t

Re: gnulib-tool problem with off64_t and Emacs

NANOSLEEP@ HAVE_NATIVE_COMP = @HAVE_NATIVE_COMP@ +HAVE_OFF64_T = @HAVE_OFF64_T@ HAVE_OPENAT = @HAVE_OPENAT@ HAVE_OPENDIR = @HAVE_OPENDIR@ HAVE_OS_H = @HAVE_OS_H@ The order in which gnulib-tool creates the files seems to be correct: lib/gnulib.mk.in is generated last. ... Replacing file m4/nst

Re: gnulib-tool sh+py mismatch when updating Emacs

d slow machine.) I've applied the attached patch. CollinFrom 987535a15d4d2902818661feb6d6b363e4d7af2b Mon Sep 17 00:00:00 2001 From: Collin Funk Date: Sat, 4 May 2024 23:46:02 -0700 Subject: [PATCH] gnulib-tool: Ignore autom4te.cache when using GNULIB_TOOL_IMPL=sh+py. Reported by Paul Egg

Re: gnulib-tool sh+py mismatch when updating Emacs

On 2024-05-04 16:03, Collin Funk wrote: I noticed in your emacs/output.0 it says "Generated by GNU Autoconf 2.71". I was using Autoconf 2.72 on my system. Ah, I am using Autoconf 2.71, which is what's in /usr/bin/autoconf on Fedora 40. It comes from the autoconf-2.71-10.fc40.noarch package,

Re: gnulib-tool sh+py mismatch when updating Emacs

/output.0 it says "Generated by GNU Autoconf 2.71". I was using Autoconf 2.72 on my system. Using my Emacs directory and Autoconf ./configure'd from the v2.71 tag: $ LC_ALL=en_US.utf8 GNULIB_TOOL_IMPL=sh+py admin/merge-gnulib ../gnulib/gnulib-tool: *** gnulib-tool.py pr

Re: gnulib-tool sh+py mismatch when updating Emacs

On 5/4/24 3:02 PM, Paul Eggert wrote: > The attached build log shows what I got. The last 'grep' command shows the > bug, as lib/gnulib.mk.in uses HAVE_OFF64_T without defining it. > > This invocation of admin/merge-gnulib uses a nearly-empty environment and an > empty home directory, to lessen

Re: gnulib-tool sh+py mismatch when updating Emacs

On 2024-05-04 13:45, Collin Funk wrote: I can't reproduce this (using Fedora 40). That's odd, as I just now reproduced it on Fedora 40 x86-64 using the following from-scratch recipe: mkdir new empty empty_home=$PWD/empty cd new git clone git://git.sv.gnu.org/emacs.git (cd e

Re: gnulib-tool sh+py mismatch when updating Emacs

Hi Paul, On 5/4/24 9:03 AM, Paul Eggert wrote: > Some sort of locale problem? The issue seems to be benign, except that it's a > false positive when testing. > > To reproduce it, clone current gnulib (commit > fde88b711c9b1df5b142444ac7b0bc2aa8892d3a) and current emacs (commit > fd859fbea2e9d1

Re: gnulib-tool problem with off64_t and Emacs

by this: ## begin gnulib module sys_types ifeq (,$(OMIT_GNULIB_MODULE_sys_types)) The ifeq succeeds and sys/types.h is being built. I can reproduce the problem in fresh emacs and gnulib checkout siblings (same commits as before) by running the following in the emacs directory. This invo

Re: gnulib-tool problem with off64_t and Emacs

Hi Paul, > but there was no "HAVE_OFF64_T = @HAVE_OFF64_T@" line Strange. The AC_SUBST([HAVE_OFF64_T]) in m4/off64_t.m4 should produce such a line. Do you see the 'sys_types' module enabled? Or maybe it is only conditionally enabled? > It strikes me that apps like Emacs and coreutils don't need

gnulib-tool problem with off64_t and Emacs

I had problems updating Emacs to use gnulib commit fde88b711c9b1df5b142444ac7b0bc2aa8892d3a along with emacs commit fd859fbea2e9d13e76db1c5295d9ddd1c5955d83 (these are the same commits as I mentioned earlier today). I reproduced it like this: cd emacs admin/merge-gnulib The resulting lib/gnul

gnulib-tool sh+py mismatch when updating Emacs

e-push' -> '.git/hooks/pre-push' 'build-aux/git-hooks/commit-msg-files.awk' -> '.git/hooks/commit-msg-files.awk' '.git/hooks/applypatch-msg.sample' -> '.git/hooks/applypatch-msg' '.git/hooks/pre-applypatch.sample' -> &#x

Re: gnulib-tool: Use the Python implementation by default

t deserved a worse reaction; I apologize for the quality > and overall style). :-) No need to apologize! I hope any criticism that I had didn't come off harsh. If someone told me to rewrite 'gnulib-tool' from scratch the result of my work would be *far* worse than yours. Thank you for doing the hard work for me! :D Collin

Re: gnulib-tool: Use the Python implementation by default

Hi Dmitry, The biggest "thank you" is yours, since you did the majority of the work (my estimations: you 4 months, Collin 2 months, me 1 month). OO is hard. I was and am still impressed about how your dissection of the code into classes (GLConfig, GLModule, GLModuleSystem, etc.) stood the test of

Re: gnulib-tool: Use the Python implementation by default

Hi folks, sorry for the long silence! I've been tracking your progress for a while, even though sporadically and remaining silent. I'd like to say "thank you" to Bruno and Collin, who made it this far and never surrendered. :-) Truth to be told, the code I implemented leaves much to be desired, an

Re: gnulib-tool: Use the Python implementation by default

On 2024-04-27 11:49, Bruno Haible wrote: - In many recent systems, 'python3' exists and 'python' does not. This includes Ubuntu 23.10 and 24.04. (No idea why it's different on your machine.) Oh, I see I have the python-is-python3 package installed on my Ubuntu platform. I had forg

Re: gnulib-tool: Use the Python implementation by default

On 4/27/24 11:49 AM, Bruno Haible wrote: > - In many older systems, 'python3' exists and 'python' exists as well and is > a 2.7.x version. > > I have not seen a single system where 'python' exists, is version 3, and > 'python3' does not exist. There is this PEP which came about with the Pyt

Re: gnulib-tool: Use the Python implementation by default

Paul Eggert wrote: > > Are there alternative Python implementations, which could be installed under > > the name 'python3'? > > On the platforms I currently have terminals open on (Fedora 40, Ubuntu > 23.10) it's called 'python'. You can also use 'python3' but I would > suggest trying 'python' f

Re: gnulib-tool: Use the Python implementation by default

he values that you have shown, it will be indeed better to use sys.version_info. > Testing shows that a subshell does avoid that issue, so the following works: > >if (python3 -c 'import sys; sys.exit(not sys.version_info >= (3,7))') > 2>/dev/null; t

Re: gnulib-tool: Use the Python implementation by default

On 2024-04-27 06:32, Bruno Haible wrote: Are there alternative Python implementations, which could be installed under the name 'python3'? On the platforms I currently have terminals open on (Fedora 40, Ubuntu 23.10) it's called 'python'. You can also use 'python3' but I would suggest trying '

Re: gnulib-tool: Use the Python implementation by default

On 27/04/2024 14:32, Bruno Haible wrote: Hi Pádraig, +if (python3 --version) >/dev/null 2>/dev/null \ + && case `python3 --version 2>&1` in +Python\ 3.[0-6] | Python\ 3.[0-6].*) false ;; +Python\ 3.*) true ;; +*) false ;; + esac; then It

Re: GNU gnulib: gnulib-tool has become much faster

On 2024-04-27 10:11, Tim Rühsen wrote: Bruno, Dmitry, Collin, thank you so much ! The runtime improvement is amazing :) Likewise. This is very much appreciated, especially on some of the trusty but old and slow hosts that I develop on.

Re: GNU gnulib: gnulib-tool has become much faster

Bruno, Dmitry, Collin, thank you so much ! The runtime improvement is amazing :) Regards, Tim On 4/26/24 12:14, Bruno Haible wrote: 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

Re: gnulib-tool: Use the Python implementation by default

Hi Pádraig, > > +if (python3 --version) >/dev/null 2>/dev/null \ > > + && case `python3 --version 2>&1` in > > +Python\ 3.[0-6] | Python\ 3.[0-6].*) false ;; > > +Python\ 3.*) true ;; > > +*) false ;; > > + esac; then > > It may be preferable

Re: gnulib-tool: Use the Python implementation by default

On 26/04/2024 10:48, Bruno Haible wrote: I committed this patch, which activates the Python rewrite of gnulib-tool for all users who have Python installed, without the need to set any environment variable. I'll make announcements to info-gnu and planet.gnu.org soon. +if (python3 --ve

  1   2   3   4   5   6   7   8   9   10   >