Re: new module 'access'
> 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)
> +{
> + if ((mode & X_OK) != 0)
> +mode = (mode & ~X_OK) | R_OK;
> + return _access (file, mode);
This implementation is IMO less useful than it could be: it could also
look at the file-name extension and see if it's one of the known
executable extensions.
Thanks.
Re: [PATCH] findprog-in: Set errno to indicate why NULL was returned.
> 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 but lacks the > + execute permissions. The value of EACCES (not EACCESS!) on MS-Windows frequently means the file cannot be accessed for a reason that has nothing to do with execute permissions. It could be, for example, that some intermediate directory in the full file name doesn't exist or is otherwise inaccessible.
Re: Why does gnulib use makefile rules rather than configure?
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 instead of 'make' rules. I enhanced GNU make's build.sh to be fancy enough to manage some basic substitutions, which are good enough for the current suite of gnulib modules. We'll see what happens in the future! 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 of handling it, configuration.ac should be preferred over Makefile. I understand I'm probably the only person who cares. > On the other hand perhaps it's time to stop worrying about building > GNU make without a 'make'. We don't worry that GCC can't be built > on a system without a C compiler, so why worry about building GNU > Make on a system without 'make'? Well, IMO the two situations are not comparable: no one would expect a C compiler to be written in (for example) assembly (and anyway what would your assembler be written in... maybe sh?!?! :)). I take your point but I daresay that if GCC had managed to not require a C compiler to build itself, somehow, they would surely be unhappy about ditching this very useful capability in order to satisfy gnulib module builds :). Similarly I'm loathe to ditch this "make-less build" capability for GNU make unless/until there's no alternative.
Re: Why does gnulib use makefile rules rather than configure?
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 of > handling it, configuration.ac should be preferred over Makefile. There are several reasons why gnulib uses Makefile.am snippets: * [As Paul mentioned] sed substitutions in a Makefile rule are more powerful than those supported by AC_CONFIG_FILES. * There are cases in which we want to have a file generated in some conditions only. (Example: modules/limits-h.) In such a case, there is the need to remove the file when the developer switches from a configuration which needs a generated limits.h to one that doesn't. There is no place in configure.ac where this removal could be done. Developers not always use make -k distclean; ./configure; make Sometimes they also do ./configure; make clean; make and in such situations a mix between a generation rule in configure.ac and a removal rule in the Makefile does not work well. * The file hierarchy of the package is not something Gnulib can dictate; it has to obey the file hierarchy given by the package's developers. Through a long and painful experience (Jim may remember the AC_LIBOBJ controversy...) we arrived at the conclusion that - putting file/directory names into .m4 files must be avoided, - putting file/directory names into the configure.ac part of a module description can be done but needs careful coding, - putting file/directory names into a Makefile.am snippet is a no-brainer. * Some packages build specific subdirectories only in specific conditions. For example, GNU gettext builds its libasprintf/ directory only when a C++ compiler is present. When you have a configure.ac rule that generates a file in such a directory, it basically bypasses the decision of the top-level Makefile whether to build the particular subdirectory. Again, this presents the risk of left-over files after "make distclean", and similar trouble. Therefore I disagree with your proposed "statement of policy". Bruno
Re: new module 'access'
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 against an older MSVCRT
runtime. If/when mingw starts to link against newer Microsoft ucrt runtimes,
it will be affected by the same problem.
> > +int
> > +access (const char *file, int mode)
> > +{
> > + if ((mode & X_OK) != 0)
> > +mode = (mode & ~X_OK) | R_OK;
> > + return _access (file, mode);
>
> This implementation is IMO less useful than it could be: it could also
> look at the file-name extension and see if it's one of the known
> executable extensions.
Should it look whether the file name contains a '.'? (Recall that
files without a '.' are not executable by execlp/execvp.) Yes, it could
be done. But I don't see a compelling argument to do it, so far.
Should it look whether the file extension is one of the known ones?
Definitely not. When you rename a file prog.exe to prog.foo and invoke
it through execlp/execvp, it works. And '.foo' is surely not one of the
"known" file extensions.
Bruno
Re: new module 'access'
> 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 enabled this code also on mingw. With the mingw version I tested,
> it is a no-op, because that mingw version links against an older MSVCRT
> runtime. If/when mingw starts to link against newer Microsoft ucrt runtimes,
> it will be affected by the same problem.
I'm saying that the documentation should mention MinGW as well,
because currently it gives an impression that only MSVC builds are
affected in any way.
> > > +int
> > > +access (const char *file, int mode)
> > > +{
> > > + if ((mode & X_OK) != 0)
> > > +mode = (mode & ~X_OK) | R_OK;
> > > + return _access (file, mode);
> >
> > This implementation is IMO less useful than it could be: it could also
> > look at the file-name extension and see if it's one of the known
> > executable extensions.
>
> Should it look whether the file name contains a '.'? (Recall that
> files without a '.' are not executable by execlp/execvp.) Yes, it could
> be done. But I don't see a compelling argument to do it, so far.
>
> Should it look whether the file extension is one of the known ones?
> Definitely not. When you rename a file prog.exe to prog.foo and invoke
> it through execlp/execvp, it works. And '.foo' is surely not one of the
> "known" file extensions.
You describe a very unusual situation, because prog.foo will not be
found by the Windows shell and by many other programs that use the
shell via the likes of 'system' and 'popen'. I think it's better to
be 90% correct than do nothing about this issue because we cannot
easily be 100% correct. Callers don't usually expect an X_OK test to
degenerate into F_OK, IMO.
IOW, I think this implementation doesn't live up to Gnulib's promise
to be a portability layer, because it loses too much of the baby with
the bath water.
