Re: dependency on libperl?

Patrice Dumas wrote: > > The second is as a result of the SWIG stuff, which looks like is > > happening here. > > Indeed, there is no proper check of libperl being present ... > > So, it would be good to add an autoconf check similar to the one > checking for the possibility to embed Perl. I'll

dependency on libperl?

The CI reports a link error on Ubuntu (both when compiling natively and when cross-compiling for RISCV), that was not present last week: /bin/bash ../../libtool --tag=CC --mode=link x86_64-linux-gnu-gcc -module -o _Texinfo.la -rpath /usr/local/lib/python3.10/site-packages _Texinfo_la-pyth

compilation error on NetBSD

The CI reports a compilation error on NetBSD 10.0: gcc -DHAVE_CONFIG_H -I. -I../../info -I.. -I../.. -I../../gnulib/lib -I../gnulib/lib -DLOCALEDIR=\"/usr/local/share/locale\" -DINFODIR=\"/usr/local/share/info\"

Re: "make distcheck" failure

Gavin Smith wrote: > Thanks for the report and apologies for the inconvenience. I have fixed > in commit 9ce27563568c (today's date). OK, I'm starting a new CI run (because you certainly want to know if there happen to be other regressions). Bruno

"make distcheck" failure

Hi, The CI reports today that, unlike a week ago, "make distcheck" fails: (cd info && make top_distdir=../texinfo-7.2.20250721dev distdir=../texinfo-7.2.20250721dev/info \ am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir) make[3]: Entering directory '/home/runner/w

Re: 'info' navigation on an index entry brings me to a wrong node

2024-12-30 Gavin Smith > + > + ". " terminator for index entry node name > + > + * info/scan.c (scan_reference_target): > + First check for a ". " and ".\n" terminator for node name in menu, > + rather than just a ".". This a

'info' navigation on an index entry brings me to a wrong node

Hi, In the 'info' program, when the user selects an index entry, it should display the node associated with that index entry. Instead, in some cases it displays a different node, with a similar name. Reproduced with texinfo 7.1 and 7.2. How to reproduce: (I noticed this with the gnulib.info file.

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

Re: Interactive links in the TOC go to the page start, not the section start

Gavin Smith wrote: > > >> Trying out this new feature – which is great! – I have to agree > > >> with Bruno: That I get two different positions depending on whether > > >> I click on the title or on the page number is unexpected (and I > > >> haven't seen such a feature in other PDF documents, as f

Re: Texinfo 7.1.90 on Solaris 11 OmniOS

Patrice Dumas wrote: > I do not have a good understanding, actually, whether the CI > system we use is transparent in that it could be reproduced somewhere > else or not. Generally, in 90% or 95% of the cases, I can reproduce CI failures locally on VMs that run on my own hardware or on compilefarm

Re: Interactive links in the TOC go to the page start, not the section start

Hi Gavin, Gavin Smith wrote: > You're right. The link from the entry text to the page was only added > on 2022-12-03; before that, only the page number was linkized. > > I have attempted a fix (024a4e8bb3, 2024-10-28). Thanks! That works nicely, both in okular and firefox. And what about the p

Interactive links in the TOC go to the page start, not the section start

Hi, PDF readers, like HTML document viewers, have the ability to position the canvas in such a way that any specified line is at the top. (DVI viewers like 'xdvi' and PostScript viewers like 'ghostscript' don't have this ability.) Texinfo-generated PDF files make use of this feature for hyperlink

Re: Texinfo 7.1.90 on Solaris 11 OmniOS

Gavin Smith wrote: > This appears to be a similar error to > that which you reported earlier for Solaris 11 OmniOS for an earlier > version of the code, Texinfo pretest 7.1.0.90, with an extra "0" file > being created: > > https://lists.gnu.org/archive/html/bug-texinfo/2024-06/msg00027.html > http

Re: Texinfo 7.1.90 on mingw

Eli Zaretskii wrote: > > Cygwin does a similar thing; not inside bash but inside its fork+exec() > > system calls (which bash uses, of course). [4] > > Not entirely, because, for example, /dev/null is left unchanged. Fortunately Cygwin does not do this sort of heuristic substitutions in argv[1..a

Re: Texinfo 7.1.90 on mingw

Eli Zaretskii wrote: > MinGW programs are stand-alone native Windows executables. But the > MinGW development environment includes MSYS Bash and MSYS ports of > various GNU utilities, ... It is *one* of the possible development environment for mingw. [1] However, I cannot recommend it because it

Re: Texinfo 7.1.90 on mingw

Patrice Dumas wrote: > All in all, this is already unhoped-for that we can manage to have most > of the tests passing on such a broken platform! I agree. *Only* 6 failures on mingw is an achievement! > Those errors are expected. Would you mind marking them as expected failures? This would have t

Re: Texinfo 7.1.90 on mingw

On mingw (both 64-bit and 32-bit) there are 6 test suite failures. Find attached the log file tp/tests/test-suite.log for 64-bit mingw. == GNU Texinfo 7.1.90-20241025: tp/tests/test-suite.log ===

Re: Texinfo 7.1.90 on Solaris 11 OmniOS

On Solaris 11 OmniOS, there is 1 test failure: FAIL: test_scripts/encoded_non_ascii_test_epub.sh = D: encoded/diffs/non_ascii_test_epub.diff (printed below) Common subdirectories: ../../../tp/tests/encoded/res_parser/non_ascii_test_epub/osé_utf8_e

Re: distribution of texi2any_internals.info

Gavin Smith wrote: > I found the change was made in commit 1db4e2d2fd18b (2024-07-26) on the > master branch, which change I then propagated onto the release/7.1 branch > as part of other build system fixes. Commit 1db4e2d2fd18b is on the release/7.1 branch. The corresponding commit on the master

Re: Texinfo 7.1.0.91 pretest results, mingw

Hi Gavin, > I don't know if this is a silly question but why does build say > "Build in cygwin" if it is the mingw32 build? mingw32 is not the same > platform as cygwin. Is this cross-compiling? Oh, you got deep into philosophers' arguments. Too many simplifications and words for concepts that

Re: Texinfo 7.1.0.91 pretest results

Hi Gavin, > > Can't locate Texinfo/ModulePath.pm in @INC (you may need to install the > > Texinfo::ModulePath module) (@INC contains: > > \cygdrive\d\a\ci-check\ci-check\texinfo-7.1.0.91-20240901\build\tp > > C:/Strawberry/perl/site/lib C:/Strawberry/perl/vendor/lib > > C:/Strawberry/perl/lib)

Re: Texinfo 7.1.0.91 pretest results

The automated build recipe for several platforms - Ubuntu GNU/Linux 22.04 - CentOS GNU/Linux 7 - AlmaLinux 9 - Alpine Linux - macOS 12, 13 (all x86_64) - macOS 14 (arm64) - FreeBSD 14.0 - NetBSD 10.0 - OpenBSD 7.5 - Solaris 11.4 - Solaris 11 OmniOS - Cygwin 3.3.6 (32 bit) an

build failure on Solaris 11.4

able for the options only. The attached patch fixes the 60 failures. Bruno >From a6fd002aa7f457756dddcea836238f4b245ada57 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Tue, 20 Aug 2024 00:28:49 +0200 Subject: [PATCH] build: Fix failure of all install-info tests on Solaris 11.4. * install-info/

Re: Texinfo 7.1.0.90 pretest results [mingw]

Hi Gavin, > If someone could confirm that this works for mingw where > --strip-trailing-cr is needed for diff The current texinfo from git builds fine, with all tests passed!, on mingw 5.0 in a Cygwin environment. Very nice! But there is a regression in the install-info directory on Solaris 11.

Re: fix an error message during configure

Gavin Smith wrote: > Also, if I delete build-aux/ar-lib nothing appears to regenerate it. Yes, I made the same experience. 'ar-lib' needs to be imported explicitly. > Perhaps it is not needed. It is needed for building with the MSVC compiler. Cf. https://git.savannah.gnu.org/gitweb/?p=gettext.gi

Re: fix an error message during configure

Gavin Smith wrote: > I'm not sure applying a patch such as this is the best way to upgrade > these files. If these files came from Automake then it would make sense > to update them from the Automake release with an installed version of > Automake by running "automake" or similar (it's probably do

Re: fix an error message during configure

Gavin Smith wrote: > > The first part serves the purpose of updating the same files also > > in the build-aux/ directory, so that you don't risk distributing > > outdated files for 6 years any more :) ... > ... I'm not sure which files you are saying were 6 years out of date. When comparing the c

Re: another build system suggestion

Gavin Smith wrote: > However, I have no understanding of why we track > one file and not the others. config.rpath comes from gnulib, and you have the habit of putting all gnulib-imported files under version control. Whereas the other files (config.guess, missing, etc.) come from Automake. Bruno

another build system suggestion

Texinfo already has 2 build-aux/ directories, but in the tp/Texinfo/XS/ the automake-imported files are cluttering the main directory. How about moving them to a build-aux/ directory there as well? Doing that consists of 3 steps: 1) Apply this patch: diff --git a/tp/Texinfo/XS/configure.ac b/tp/

Re: Fix an error during "./configure; make dist"

Hello Patrice, > I attach a list of recipes mainly based on Bruno, maybe this should be > added to the list of the things to check before a release? I also have a couple of recipes (in a different format) at https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=gettext-tools/examples/check-

Re: Fix an error during "./configure; make dist"

Patrice Dumas wrote: > also a difference in *.pot files > in POT-Creation-Date, which seems to be updated at each make dist. I > attach the diff. > > I had a look at internet on the POT-Creation-Date subject but found > nothing clear. I don't know if it is the reason, but I think that some > fil

Re: fix an error message during configure

part serves the purpose of updating the same files also in the build-aux/ directory, so that you don't risk distributing outdated files for 6 years any more :) But it assumes that the main contributors are all on the same Automake version, otherwise one guy gets differences, commits them, and then th

Re: Fix an error during "./configure; make dist"

Patrice Dumas wrote: > I think > that we sould make sure that there are no differences at all between in > source and out of source distributions. This should not be difficult > for some file we generate, but there are also some gperf generated files > in gnulib that have some srcdir prepended, wh

Re: Fix an error during "./configure; make dist"

Patrice Dumas wrote: > > > Here is a recipe to get differences between in source and out of source > > > distributions. There are some changes for generated files, which seem > > > innocuous, but may be an issue for reproductibility, as well as the > > > difference for texi2any_internals.texi. > >

Re: fix an error message during configure

Gavin Smith wrote: > The "autogen.sh" script at the root of the > Texinfo repository runs autoreconf under tp/Texinfo/XS. Now it runs > autopoint: > > $ autoreconf --force --verbose --install > autoreconf: export WARNINGS= > autoreconf: Entering directory '.' > autoreconf: running: autopoint --fo

Re: fix an error message during configure

Gavin Smith wrote: > Line 145 is newly added: > > +# serial number (from gnulib) to an older serial number (from gettext). > > The comment is being interpreted as some kind of serial number line. Oh, what a bad luck. Yeah, the pattern is '# serial '.[1] Bruno [1] https://www.gnu.org/software/au

Re: Fix an error during "./configure; make dist"

Hi Gavin, > I am sure I ran "make distcheck" several times when testing this, but > not with the "make maintainer-clean" first. In fact, I have never run > "make maintainer-clean" and didn't know it was important. I don't know _why_ "make distcheck" works differently after "make maintainer-clean

fix an error message during configure

d of older versions (from gettext), a downgrade is not recommended. 3) Commit the file tp/Texinfo/XS/gnulib/m4/intlmacosx.m4 under version control, like the gettext.m4 file in the same directory. Bruno >From e738aab3f63588f4ec8be6aaa469fdca6ce29d99 Mon Sep 17 00:00:00 2001 From: Bruno Ha

Re: Fix an error during "./configure; make dist"

Hi Gavin, > In the other commit I made (a78e787fe3a) it was a simpler fix than the > one you sent - hopefully it doesn't make a difference. (I want to keep > it as simple and comprehensible as possible ... Well, there is a reason that the patches I submitted contain this "move-if-changed" logic

Re: Fix an error during "./configure; make dist"

eaving directory '/TEXINFO/texinfo/doc' make[2]: *** [Makefile:2031: distdir-am] Error 1 make[2]: Leaving directory '/TEXINFO/texinfo' make[1]: *** [Makefile:2025: distdir] Error 2 make[1]: Leaving directory '/TEXINFO/texinfo' make: *** [Makefile:2130: dist] Error 2 &g

Re: Fix an error during "./configure; make dist"

ame file being present (in different versions) in the source dir and in the build dir. The attached patch fixes it. Tested. Bruno >From 09c76d3172ed0246e5a5f5bc2b1a214c65f48298 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Mon, 5 Aug 2024 13:39:31 +0200 Subject: [PATCH] build: Fix a &quo

Re: Fix an error during "./configure; make dist"

Patrice Dumas wrote: > I do not know if it is the same, but here is a patch that adds the > ModulePath.pm dependency and a rule for tp_api, which seems to be needed > for a out of source build without a prior make all in doc/tp_api. Nice and simple. Note that double-quotes are not needed around $

Fix an error during "./configure; make dist"

'/TEXINFO/texinfo/doc' make[2]: *** [Makefile:2028: distdir-am] Error 1 make[2]: Leaving directory '/TEXINFO/texinfo' make[1]: *** [Makefile:2022: distdir] Error 2 but I'm not proposing a fix for this one since I am not familiar with this part of GNU texinfo. >From f

Re: Texinfo 7.1.0.90 pretest results [mingw]

I wrote: > I'll use Cygwin's perl in the Cygwin builds now. Indeed, this fixed all the test failures on Cygwin! Thanks, Ken. Bruno

Re: Texinfo 7.1.0.90 pretest results [mingw]

Ken Brown wrote: > >>- On Cygwin and mingw, there are many test failures, some of which > >> look like CR-LF / LF mismatches. > > I just took a look at the log on Cygwin, and the cause appears to be > that Strawberry Perl is being used rather than Cygwin's Perl. Unless > the CI does so

Re: Texinfo master branch [macOS]

Patrice Dumas wrote: > Thanks, should be fixed. Seems to help. Now, a different compilation error: libtool: compile: cc -DHAVE_CONFIG_H -I. -I../../../../tp/Texinfo/XS -I../../../../tp/Texinfo/XS/main -I../../../../tp/Texinfo/XS/parsetexi -I../../../../tp/Texinfo/XS -DDATADIR=\"/usr/local/shar

Re: Texinfo master branch [mingw]

On mingw, I see 2 compilation errors: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../info -I.. -I../.. -I../../gnulib/lib -I../gnulib/lib -DLOCALEDIR=\"/usr/local/share/locale\" -DINFODIR=\"/usr/local/share/info\" -DINFODIR2=\"/usr/local/share/info\" -Wall -g -O2 -MT infomap.o -MD -MP -MF

Re: Texinfo master branch [macOS]

Gavin Smith wrote: > > It seems like it is xlocale.h on macOS. It should be fixed by this > > commit: > > > > https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=5efd627915bd05d4c265f111991d371e0b5cfd27 > > I don't see why we need to include different files for macOS. Wouldn't this > be be

Re: Texinfo master branch [Solaris 11 OmniOS]

Patrice Dumas wrote: > > 4) The Solaris 11 OmniOS build fails due to a test failure: > > > > FAIL: test_scripts/encoded_non_ascii_test_epub.sh > > > > Detailed log: > > --- > > > > FAIL: test_scripts/encoded_non_ascii_te

Re: Texinfo master branch [OpenBSD]

in my generated tarball. With GNU make, there is no problem. The bug only occurs when OpenBSD 'make' is used, in a VPATH build. The attached patch fixes the problem (I verified). It is based on https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=bf9412ab2e5878f2b64c8ba5d496d7a26ac4d374 Bruno &

Re: Texinfo master branch [macOS]

Patrice Dumas wrote: > > 2) On macOS 11..13, there is a compilation error: > > I would guess that the cause is a missing '#include '. > > It seems like it is xlocale.h on macOS. It should be fixed by this > commit: > > https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=5efd627915bd05d4c265

Re: Texinfo 7.1.0.90 pretest results [OpenBSD 7.5]

Gavin Smith wrote: > I tried to fix one problem on the master branch (commit 2ae196b9807a, > 2024-06-09). Since you mention the master branch, I ran the same build recipe on the master branch. Results (compared with the release/7.1 branch): 1) On OpenBSD, the error "Can't locate Texinfo/Commands.

Re: Texinfo 7.1.0.90 pretest results [OpenBSD 7.5]

Gavin Smith wrote: > > [2] https://github.com/gnu-texinfo/ci-check/actions/runs/9432971359 > > (I had to log into a Github account to download this.) Sorry about that. Next time, I'll attach the relevant log files to the mail. Bruno

Re: Texinfo 7.1.0.90 pretest results

Hi Gavin, This time, I did not test manually, but instead set up a automated build recipe for several platforms [1]: - Ubuntu GNU/Linux 22.04 - CentOS GNU/Linux 7 - Alpine Linux - macOS 11, 12, 13 (all x86_64) - macOS 14 (arm64) - FreeBSD 14.0 - NetBSD 10.0 - OpenBSD 7.5 - Solari

Re: @itemize @asis is not well supported

Gavin Smith wrote: > it is not worth changing and making practically every use of > @itemize in a Texinfo manual being flagged as incorrect, in my opinion. I agree. Counting the number of existing usages in Debian [1][2]: - 8753 times '@itemize @bullet' without braces, - 288 times '@itemize @b

Re: @itemize @asis is not well supported

Patrice Dumas wrote: > > The command after @itemize should not require an argument, but @asis > > needs an argument. Try @asis{} instead. > > The command after @itemize should not require an argument, but @code > > needs an argument. Try @code{} instead. > > What about > > @itemize comman

Re: @itemize @asis is not well supported

Andreas Schwab wrote: > It's not a might, it's a don't do it. It's a misuse of a command that > requires an argument, in a place that doesn't pass one. Thanks for the succint formulation. Can we use it in the warning? The command after @itemize should not require an argument, but @asis needs a

Re: @itemize @asis is not well supported

Patrice Dumas wrote: > Ok, I propose as warning message : > > "non-mark brace command `\@%s' as \@%s argument should have braces" > > leading to something like > > non-mark brace command `@asis' as @itemize argument should have braces This is not easy to understand. How about @itemize argu

Re: @itemize @asis is not well supported

Patrice Dumas wrote: > @itemize @asis is definitely not the same as @table @asis. Indeed, > @table argument is applied to the @item argument, while @itemize > argument precedes the @item argument. Ah, thanks for explaining. It also explains why @itemize @code did not have the desired effect, w

@itemize @asis is not well supported

@itemize @asis seems to work in HTML and info mode only, not in TeX mode. How to reproduce (with texinfo-7.1): $ git clone git://git.savannah.gnu.org/gnulib.git $ cd gnulib $ git checkout f52d4a7b78be73060cf01640b40ebc88193c12e8 $ cd doc $ make pdf ... /tmp/gnulib/doc/gnulib-tool.texi:472: Argum

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Gavin Smith wrote: > It is surprising it worked as well as it did with mixing the two different > struct definitions. Yes. Probably because the alignment only matters on sparc64 and ia64 machines, and because no new features were added to this module in 20 years. > Thanks for the detailed investi

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Sam James wrote: > > It appears that the obstack gnulib module is the culprit. I replied: > Therefore, if it is a bug in gnulib, it is also a bug in glibc. Sam was right. I was wrong. It is a bug in the 'obstack' gnulib module. The scope - It is visible on CPUs that are - big-endian

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Hi Jeffrey, > On SPARC, 64-bit words can be loaded and saved through one of two > instructions. The first version is optimized, the second version is > not. The optimized version is faster, but the 64-bit words have to be > aligned to 8-byte boundaries. I.e., naturally aligned. > > If you are per

Re: obstack module has alignment issues on sparc? (Re: set_labels_identifiers_target -fsanitize=undefined error)

Sam James wrote: > It appears that the obstack gnulib module is the culprit. When I compile texinfo-7.1 in such a way that is uses the obstack facility from glibc (via 'gl_cv_func_obstack=yes ../configure ...'), I see the same bus error as in a build where the obstack facility comes from gnulib.

CC and CFLAGS are ignored by part of the build

Hi, I'm trying to build texinfo-7.1 on Linux/sparc64, in order to debug a problem. I configured the package with CC="gcc -fsanitize=undefined" \ CFLAGS="-O0 -fno-omit-frame-pointer -ggdb" \ gl_cv_func_obstack=yes \ ../configure --prefix=$HOME/prefix64 \ CPPFLAGS="

Re: c32width gives incorrect return values in C locale

[CCing bug-libunistring] Gavin Smith wrote: > I did not understand why uc_width was said to be "locale dependent": > > "These functions are locale dependent." > > - from > . That's because some

Re: c32width gives incorrect return values in C locale

[CCing bug-gnulib] Gavin Smith wrote: > > I guess you will need to look at the Unicode characters that you pass to > > c32width, > > and whether you get return values < 1 for some of them. > > It is locale-dependent! > > It looks like c32width is simply being redirected to wcwidth which then > d

Re: Locale-independent paragraph formatting

> > From: Gavin Smith > > Date: Thu, 9 Nov 2023 21:26:11 + > > > > I have just pushed a commit (e3a28cc9bf) to use gnulib/libunistring > > functions instead of the locale-dependent functions mbrtowc and wcwidth. > > This allows for a significant simplification as we do not have to try > > to

Re: MinGW "info" program broken?

Eli Zaretskii wrote: > > It happens also with the mingw-w64 version 5.0.3 build. Let me > > investigate... > > Is this build with UCRT or with MSVCRT? The mingw-w64 5.0.3 built ginfo.exe is linked with MSVCRT. Only the MSVCRT built ginfo.exe is linked with the various api-ms-win-crt-*.dll, that

Re: Texinfo 7.0.94 on native Windows

Eli Zaretskii wrote: > _popen accepts a MODE argument which can be used to control that, see > > > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/popen-wpopen?view=msvc-170 > > We use this in the stand-alone Info reader, for example, in this > snippet from info/filesys.c: >

Re: MinGW "info" program broken?

Eli Zaretskii wrote: > The stand-alone Info reader built with MinGW works > flawlessly for me. > > > I had understood that "info" was running well on MinGW so it would be worth > > understanding any differences between yours and Bruno's setup. > > I'm indeed curious why this happens with the MSVC

Re: MinGW "info" program broken?

Gavin Smith wrote: > I had understood that "info" was running well on MinGW so it would be worth > understanding any differences between yours and Bruno's setup. I'm usually building with mingw-w64 5.0.3. Whereas Eli (AFAIK) often builds with the older mingw from the now-defunct mingw.org site. C

Re: Texinfo 7.0.94 on native Windows

Eli Zaretskii wrote: > > For 'popen' and 'pclose', one needs the gnulib modules 'popen' and 'pclose', > > respectively. > > Windows has _popen and _pclose, which can be used instead. _popen uses text mode, not binary mode, by default, AFAIK. This can be problematic. Bruno

Re: Texinfo 7.0.94 on native Windows

e function pause_or_input has specific code for native Windows; thus the socket-able code with select() on stdin could probably be disabled? (This applies to both mingw and MSVC.) Note: I wouldn't push for these changes before the 7.1 release, since in particular the 'select' module can

Re: Texinfo 7.0.93 pretest available

Hi Gavin, > The module shouldn't load if it can't switch to a UTF-8 locale. xspara_init > returns a different value if these attempts fail leading the code loading > the module (in Texinfo::XSLoader) to fall back to the pure Perl version. Ah, maybe this is what did not work in Eli's case on ming

Re: Texinfo 7.0.93 pretest available

Eli Zaretskii wrote: > I think we should first explore a better > alternative: use UTF-8 functions everywhere, without relying on the > locale-aware functions of libc, such as wcwidth. For example, instead > of wcwidth, we could use uc_width. > > Is it feasible to use UTF-8 in texi2any disregardi

Re: Texinfo 7.0.93 pretest available

Gavin Smith wrote: > It is supposed to attempt to force the locale to a UTF-8 locale. You > can see the code in xspara_init that attempts to change the locale. There > is also a comment before xspara_add_text: > > "This function relies on there being a UTF-8 locale in LC_CTYPE for > mbrtowc

Re: Texinfo 7.0.93 pretest available

Eli Zaretskii wrote: > > From: Bruno Haible > > Cc: bug-texinfo@gnu.org > > Date: Mon, 09 Oct 2023 18:15:05 +0200 > > > > Eli Zaretskii wrote: > > > unless the locale's codeset is UTF-8, any character that is not > > > printable _in_

Re: Texinfo 7.0.93 pretest available

Eli Zaretskii wrote: > unless the locale's codeset is UTF-8, any character that is not > printable _in_the_current_locale_ will return -1 from wcwidth. I'm > guessing that no one has ever tried to run the test suite in a > non-UTF-8 locale before? I just tried it now: On Linux (Ubuntu 22.04), in

Re: Texinfo 7.0.93 pretest on CentOS Stream 9

On CentOS Stream 9, the configuration aborts right away: checking Perl version and modules... no configure: error: perl >= 5.8.1 with Encode, Data::Dumper and Unicode::Normalize required by Texinfo. This is an improvement, compared to my previous report https://lists.gnu.org/archive/html/bug

Re: Texinfo 7.0.93 pretest

The compilation succeeds, and "make check" has all tests pass on: * Linux: - Ubuntu 22.04 - Debian 9.1 - Debian 12 - OpenSUSE Leap 15.5 - Slackware 15 - CentOS 8-stream (This means the previously reported failure https://lists.gnu.org/archive/html/bug-texinfo/2023-09/msg00040.h

Re: Texinfo 7.0.92 pretest on AIX 7.3.1

Gavin Smith wrote: > Once a pretest is out and tested, and builds successfully on some platforms, > I am loth to update gnulib again and risk breaking the build. > ... > At the time of a release, the Gnulib checkout is set in stone. It will not > be updated as a matter of course for any bug-fix re

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

Hi Patrice, > As a side note, it would have been better to have a specific variable > like LTLIBUNISTRING instead of using the global CPPFLAGS, but it is not > a big deal either. The absence of such a variable INCLIBUNISTRING is a trade-off between convenience and complexity. -L and -Wl options

Re: Texinfo 7.0.92 pretest on CentOS 8-stream

Patrice Dumas wrote: > > So, as I understand it, this test failure will remain. > > Actually it should not, the test should have been skipped, it was > supposed to be fixed by this commit: > > https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3 This

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Patrice Dumas wrote: > > FAIL: different_encodings.sh > > There was the same kind of errors on N Beebe builds (I missed your > original report). It is is supposed to be fixed by > https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=e34a8d6b66d0518a2c1673da62c56b60f87151e3 I confirm: With th

Re: Texinfo 7.0.92 pretest on other platforms

The compilation succeeds, and "make check" has all tests pass on: * Linux: - Ubuntu 22.04 - Debian 9.1 - Debian 12 - OpenSUSE Leap 15.5 - Slackware 15 - Manjaro 17 (both in 32-bit and 64-bit mode) * Alpine Linux 3.14 * GNU/Hurd * macOS 12.5 * FreeBSD 13.2 * OpenBSD 7.2 * AIX 7.1 and 7.3

Re: Texinfo 7.0.92 pretest on NetBSD 9.0

On NetBSD 9.0, with a GNU libiconv 1.0 installed, I see this build failure: $ gmake ... /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../../../tp/Texinfo/XS/gnulib/lib -I../.. -Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef

Re: Texinfo 7.0.92 pretest on CentOS Stream 9

On CentOS Stream 9, "make check" fails with 52 test failures. Find attached the log files. centos9-logs.tar.gz Description: application/compressed-tar

Re: Texinfo 7.0.92 pretest on CentOS 8-stream

On CentOS 8-stream, I still see this test failure: FAIL: different_encodings.sh Already reported in https://lists.gnu.org/archive/html/bug-texinfo/2023-08/msg00053.html Last time, you wrote: > Even though there is > a stub for Unicode::Collate, the tests will not all pass without it. > "configur

Re: Texinfo 7.0.92 pretest on AIX 7.3.1

On AIX 7.3.1, I see a compilation error: /opt/freeware/bin/gcc -maix64 -DHAVE_CONFIG_H -I. -I../../../gnulib/lib -I../.. -I/home/haible/prefix64/include -Wall -D_THREAD_SAFE -Wno-cast-qual -Wno-conversion

Re: "error: too deeply nested expressions" for large Perl input file

Gavin Smith wrote: > In gettext 0.22, there is an error running xgettext with a large input > file: > > $ /usr/local/bin/xgettextHTML.pm > HTML.pm:8052: error: too deeply nested expressions > > This makes "make update-po" break in the Texinfo package. Thanks for the report. Fixed throug

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Gavin Smith wrote: > > On CentOS 8 and CentOS 8-stream, the build now succeeds, but there is 1 test > > failure: > > > > FAIL: different_encodings.sh > > > > Find attached the tp/tests/many_input_files/test-suite.log. > > > > Can you please send the contents of the file 'diffs/different_encodin

fix syntax error in doc/Makefile.am

Some 'make' programs give a syntax error when the lines that define the commands for a target don't all start with a tab. The text editor that I use (KDE kate) highlights such lines. This patch provides a fix. Bruno diff --git a/doc/Makefile.am b/doc/Makefile.am index 69dc082a6e..e0d5209f84 100644

Re: "make dist" error

Gavin Smith wrote: > I've added rules for these and checked that they work in out-of-source > builds, and with make distcheck. Thanks. Note that this Makefile.am does not have a .NOTPARALLEL pseudo-target, therefore if people (not me, but someone else :) ) runs "make -j 4 dist", two different "ma

Re: Texinfo 7.0.90 pretest on AIX 7.3

Gavin Smith wrote: > I have committed a > change to use a temporary file in the same directory as the dir file, > which is done by extending the name of the dir file. Thanks. "make check" on AIX 7.3 now passes. No test failures. Bruno

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Gavin Smith wrote: > I've added such a stub and added a test to configure, so that a visible > warning will be printed at the end of a configure run warning about missing > Unicode::Collate. On CentOS 8 and CentOS 8-stream, the build now succeeds, but there is 1 test failure: FAIL: different_enco

"make dist" error

Hi, I'm trying to create a texinfo tarball from the current git (for testing on CentOS 8-stream...) and am getting this error: $ ./autogen.sh ... $ ./configure ... $ make ... $ make dist ... make[3]: Entering directory '/media/develdata/www-archive/source/newest/texinfo-git/texinfo/doc' make di

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Patrice Dumas wrote: > > https://lwn.net/Articles/348090/ "Re: Redhat perl != perl" > > https://lwn.net/Articles/348084/ "On properly packaging perl" > > This seems to be an old change that was reverted afterwards. This thread was in 2009. Since things are fine in CentOS 6 and 7, probably they re

Re: Texinfo 7.0.90 pretest on CentOS 8-stream (Unicode::Collate)

Gavin Smith wrote: > As the log file shows, the Unicode::Collate module is not found. Indeed: just running perl with a 1-line input $ perl use Unicode::Collate; produces an error on CentOS 8-stream, but not e.g. on Ubuntu. When I manually search for it in @INC, I don't see it installed:

Re: ISO C99 mixed declaration and statements

Gavin Smith wrote: > It may have been some MS-Windows compiler (MSVC?) that didn't support it, Yes, I too have some recollection of MSVC (9 perhaps?) not supporting it. But since MSVC 14 (released in 2015) there is no problem any more. > I am going to take out the recommendation that we check for

  1   2   3   >