GNU bug report logs - #20681
Build failure [MSYS2/MINGW64, OSX]

Previous Next

Full log

View this message in rfc822 format

From: Andreas Grünbacher <andreas.gruenbacher <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20681 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, Nick Andryshak <nandryshak <at> gmail.com>, Angelo Graziosi <angelo.graziosi <at> alice.it>
Subject: bug#20681: Build failure [MSYS2/MINGW64, OSX]
Date: Mon, 1 Jun 2015 20:41:02 +0200

2015-06-01 19:39 GMT+02:00 Eli Zaretskii <eliz <at> gnu.org>:
> ??? If it were true, set-permissions.c would compile on Windows.  It
> doesn't.

I've already explained, at length, why it currently doesn't compile, and
at least three ways of how it could be fixed.

> So there's more to this job than just copying the code.

Yes, adding some #ifdefs and autoconf checks, that kind of thing.
That's not so hard.

>> > There's also the minor (but important for Emacs) point of supporting
>> > file names with characters outside of the current system codepage,
>> > which Gnulib can only provide in UTF-8 locales, something that doesn't
>> > exist on Windows.
>>
>> This has nothing to do with get_permissions and set_permissions.
>
> It's a reason not to use Gnulib for any file-related operations in
> Emacs on Windows, because Emacs on Windows uses Unicode APIs to access
> files by their names.

So it's okay to have this function in emacs:

  src/w32.c:acl_get_file (const char *fname, acl_type_t type)

but the same interface in gnulib wouldn't be okay? Right ...

I'll stop this discussion now, you're just not making sense.

Andreas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.