> From: Paul Eggert
> Date: Tue, 9 May 2017 14:08:19 -0700
>
> I suppose it'd be nicer if Emacs could use the Gnulib versions of the
> code instead of having its own version, as that would help Emacs and
> other GNU programs share solutions better; but this would require some
> hacking and it'
> From: Bruno Haible
> Date: Tue, 09 May 2017 22:17:58 +0200
>
> Would a gnulib-wide option "ignore mingw and MSVC portability" be useful for
> Emacs?
Not as a global option, because the MinGW port of Emacs does use some
Gnulib functions.
> Would a gnulib-wide option "ignore MSVC portability" b
On 05/09/2017 01:34 PM, Bruno Haible wrote:
- windows-year2038 : define time_t as 64-bit (might involve renaming module
time to time-h)
Such a module could be useful on non-MS-Windows platforms too. The
module could support functions like localtime even on 32-bit platforms
that can't handle
On 05/09/2017 01:17 PM, Bruno Haible wrote:
Hi Eli and Paul,
I'm trying to understand whether the #ifs you are adding for Emacs could
be generalized for gnulib users other than Emacs.
On one hand, Eli writes:
Emacs dropped MSVC support a few years ago. Only MinGW, with its 2
flavors, is curre
On Tue, May 09, 2017 at 10:34:04PM +0200, Bruno Haible wrote:
> It's clear that different gnulib users need different levels of native Windows
> support. Some will want to avoid 'struct stat', some will want to use the
> ino_t
> values in struct stat.
>
> Here's my current plan: Introduce a set o
Hi,
It's clear that different gnulib users need different levels of native Windows
support. Some will want to avoid 'struct stat', some will want to use the ino_t
values in struct stat.
Here's my current plan: Introduce a set of orthogonal, transversal modules.
("transversal" in the sense that su
Hi Eli and Paul,
I'm trying to understand whether the #ifs you are adding for Emacs could
be generalized for gnulib users other than Emacs.
On one hand, Eli writes:
> Emacs dropped MSVC support a few years ago. Only MinGW, with its 2
> flavors, is currently supported, in addition to Cygwin.
On
Ken Brown wrote:
> ... Here's what I see on my Cygwin system:
>
> $ echo $TZ
> America/New_York
>
> $ date +'%Y-%m-%d %H:%M:%S %z (%Z)'
> 2017-05-03 07:29:03 -0400 (EDT)
>
> $ TZ= date +'%Y-%m-%d %H:%M:%S %z (%Z)'
> 2017-05-03 11:29:14 + (GMT)
>
> $ unset TZ
>
> $ date +'%Y-%m-%d %H:%M:%S
Hi Paul,
> > Only for Cygwin, an empty or absent TZ environment variable means GMT.
>
> That's weird; I don't know of any other system that does that.
Misunderstanding: I meant only among the platforms on Windows. I.e. for mingw
and
MSVC, an empty or absent TZ environment variable means the sys
On Mon, May 8, 2017 at 9:43 PM, Bruno Haible wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> > When you use the --lgpl option to gnulib-tool, it should replace the
>> > copyright headers of the files accordingly. If not, that's a bug in
>> > gnulib-tool.
>>
>> That wasn't happening in the latest gnul
10 matches
Mail list logo
