> From: Bruno Haible
> Cc: Paul Smith
> Date: Sun, 15 Sep 2019 19:11:25 +0200
>
> +@item
> +This function does not support the @code{X_OK} mode on some platforms:
> +MSVC 14.
This says MSVC, but the code will do the same on MinGW, right?
> +int
> +access (const char *file, int mode)
> +{
> +
> From: Bruno Haible
> Cc: Paul Smith
> Date: Sun, 15 Sep 2019 19:58:56 +0200
>
> + - Otherwise, it sets errno and returns NULL.
> + Specific errno values include:
> + - ENOENT: means that the program's file was not found.
> + - EACCESS: means that the program's file was found
On Sun, 2019-09-08 at 16:40 -0700, Paul Eggert wrote:
> Admittedly GNU Make is a special case, since you want to build it
> without having 'make'. And if it's just a few Gnulib modules and
> they're not doing anything fancy, perhaps we can modify the modules
> to use 'configure' substitutions inste
Paul Smith wrote:
> I recognize there are some situations where make snippets are really
> the best way, but it seems like they're being used even in places where
> configure.ac would be just as simple. I think it would be a good
> "statement of policy" for gnulib that if there are equivalent ways
Hi Eli,
> > +@item
> > +This function does not support the @code{X_OK} mode on some platforms:
> > +MSVC 14.
>
> This says MSVC, but the code will do the same on MinGW, right?
Yes, I enabled this code also on mingw. With the mingw version I tested,
it is a no-op, because that mingw version links
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org, psm...@gnu.org
> Date: Tue, 17 Sep 2019 00:45:03 +0200
>
> > > +@item
> > > +This function does not support the @code{X_OK} mode on some platforms:
> > > +MSVC 14.
> >
> > This says MSVC, but the code will do the same on MinGW, right?
>
> Yes, I en
