An Emacs bug report
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70415) has led me to look
at gnulib's boot-time, and I discovered a problem. I haven't studied
the code in detail, but I looked at get_windows_boot_time in
boot-time-aux.h and found two mistakes. First, there is a comment
Hi Jeffrey,
We don't need to discuss how "make install" in Autoconf and Automake should
work. Let's keep focused on the current question: how to invoke the
Autoconf and Automake programs, assuming they already exist on the user's
disk.
Thanks.
Bruno
Hi Markus,
> > Which Cygwin version, please?
>
> The log of that run contains the following line:
> Starting cygwin install, version 2.932
>
> Is that the Cygwin version?
It is not the Cygwin version, but it at least tells me that it's a recent
Cygwin version.
> All packages should be the
Hi Collin,
> Before I add Cygwin and MSYS2 to the DEPENDENCIES file can you double
> check them?
This details about the two packages are correct. But the impression that
the entire DEPENDENCIES file would give is not right. Namely, the
impression is that all users need not only 'make', 'm4',
Hi Paul,
> +2024-04-27 Paul Eggert
> +
> + stddef: work around GCC 14 stddef.h bugs
> + * lib/stddef.in.h: Do nothing if _@GUARD_PREFIX@_STDDEF_H is
> + defined, as stddef.h has already been included. This works
> + around GCC bug 114870.
> + (_GCC_NULLPTR_T): Define if
Hi Ken,
Thanks for the report.
> > First, there is a comment
> > saying that /var/run/utmp is empty on Cygwin. This is not true, at
> > least on my system. I'm running Cygwin 3.5.3, the latest stable
> > release.
In my Cygwin 3.5.3 installation, /var/run/utmp is empty. But anyway,
since
On 5/1/24 7:26 AM, Jeffrey Walton wrote:
> The shebang is wrong. I merely pointed out the portable way to write one.
I think the issue that you brought up '/usr/bin' vs. '/usr/local/bin',
as the BSDs use, is solved by Autoconf and Automake's installation
process.
They require the normal
I wrote:
> I would have preferred if you had committed each workaround in a separate
> patch, because
> - One of the two workarounds causes the major trouble on Cygwin,
> reported by Markus Mützel, therefore I have to revert it.
> - Also the fact that the documentation mentions one of the
On 5/1/24 3:50 AM, Bruno Haible wrote:
> Indeed, that is likely the explanation: All 3 programs (autoconf,
> autoheader, automake) start with '#!/usr/bin/perl', and while native
> Windows does not interpret the shebang line, the Cygwin and MSYS2 shells
> apparently do.
I created a Windows VM last
Hi Paul,
> * lib/stddef.in.h: Do nothing if _@GUARD_PREFIX@_STDDEF_H is
> defined, as stddef.h has already been included. This works
> around GCC bug 114870.
I had to revert this, since it broke Cygwin.
The workaround should be as platform specific as possible, since
fiddling with the
On 2024-05-01 15:32, Bruno Haible wrote:
I tried another workaround, consisting of adding
#undef __STDC_VERSION_STDDEF_H__
at the appropriate place, but then the Fedora 40 gcc gives a warning
about this #undef. Since neither the warning about the redefinition
nor the warning about the #undef
Hi Bruno,
Before I add Cygwin and MSYS2 to the DEPENDENCIES file can you double
check them?
I don't want to add too much detail to that file, but it is my
understanding that MSYS2 is meant for building native Windows
software. Cygwin is more of a runtime environment, though it has MinGW
packages
Hi Bruno,
On 5/1/24 5:35 PM, Bruno Haible wrote:
> This details about the two packages are correct. But the impression that
> the entire DEPENDENCIES file would give is not right. Namely, the
> impression is that all users need not only 'make', 'm4', ..., 'tar',
> but also Cygwin and MSYS2.
>
>
On 5/1/2024 4:44 PM, Ken Brown wrote:
An Emacs bug report
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70415) has led me to look
at gnulib's boot-time, and I discovered a problem. I haven't studied
the code in detail, but I looked at get_windows_boot_time in
boot-time-aux.h and found two
I noticed that the file names when running 'patch' on test-driver
weren't quoted. I guess that would cause problems in practice if you
used spaces in directories, which I have my own opinions on. :)
Since we assume POSIX shells we can just use shlex.quote() to deal
with any theoretical shell
Hi Collin,
> I can create
> testdirs on Cygwin and MSYS2. Perhaps it is best to clarify
> gnulib-tool.py is only supported there on Windows?
Yes, feel free to add a bit of text about it to the DEPENDENCIES file.
Other environments than Cygwin and MSYS2 don't need to be considered,
since the user
I pushed this patch removing getName() from GLModule, preferring
it's name variable directly. I mentioned previously I found
differentiating these a bit confusing [1]:
module.getName()
module.name
str(module)
Especially when they were mixed together in the same function or same
line.
On 5/1/24 1:51 AM, Collin Funk wrote:
> I pushed this patch removing getName() from GLModule, preferring
> it's name variable directly.
This patch fixes a mistake I made in two functions.
They took a 'module' argument which was a str. I must have not looked
at the type hint...
Since 'module' is
Collin Funk wrote:
> Since 'module' is pretty much always a GLModule, I have renamed these
> to 'module_name'.
+1
Hi Collin,
> > * We have basically three ways to deal with this (that I can see):
> > a) Update the requirements and say that a Cygwin environment with a
> > Cygwin-based Python build is required. (I tested that; so, we know
> > that works.)
> > b) Change the gnulib-tool entry-point
Hi Collin,
> Since the bug exists from GCC 7.1 ("starts from" on the report) to GCC
> 15, should those two test cases be updated? Maybe an '#if ...' or even
> just a comment so it isn't reported as a new bug in the future.
Your test program shows a failure with -O2 starting with gcc 7.
However,
On Wed, May 1, 2024 at 10:11 AM Bruno Haible wrote:
> Hi Jeffrey,
>
> We don't need to discuss how "make install" in Autoconf and Automake should
> work. Let's keep focused on the current question: how to invoke the
> Autoconf and Automake programs, assuming they already exist on the user's
>
On Wed, May 1, 2024 at 6:51 AM Bruno Haible wrote:
> [...]
> > I assume that windows doesn't do anything about the '#!/bin/sh' line.
>
> Indeed, that is likely the explanation: All 3 programs (autoconf,
> autoheader, automake) start with '#!/usr/bin/perl', and while native
> Windows does not
23 matches
Mail list logo
