Re: make -q and maintainer-makefile issues?

[Bruno Haible]

Paul,

> What's the downside to the patch to build-aux/po/Makefile.in.in?
> If it's stylistic

Yes, it's only stylistic, but with major impact. I wouldn't want to kill all
phony targets from all Makefiles, just for "make -q". Let's hear what Paul
Smith can say about it...

Bruno
-- 
In memoriam Maximilian Kolbe 

Re: errno --> errno name ?

[Bruno Haible]

Hi Bruce,

> This time the tarball includes a module file of sorts.

Good, this is what gnulib needs.

> Makefile.am:
> GEN_ERRNO_FILES = err-names.c err-names.h
> BUILT_SOURCES  += $(GEN_ERRNO_FILES)
> MOSTLYCLEANFILES   += $(GEN_ERRNO_FILES)
> nodist_include_HEADERS += err-names.h

Does the .h file need to be generated? It is much more convenient to
rely on a .h file that is platform independent.
  1) The user can look at the .h file to see whether it fits his needs,
 and can start to program before doing "gnulib-tool --add-import ...;
 ./configure; make".
  2) The user doesn't need to wonder whether the .h file contains different
 function declarations on different platforms.

> err-names.c : err-names.h
>   @test -f $@ || CC="$(CC)" $(SHELL) mk-err-names.sh

You need the C compiler for preprocessing, right? Then you shouldn't
forget about $(CPPFLAGS) and $(AM_CPPFLAGS). So change
  CC="$(CC)"
to
  CC="$(CC) $(AM_CPPFLAGS) $(CPPFLAGS)"

Also, the rule is not very robust and lacks dependencies: If one some
platform, the generation of the file fails, then you change mk-err-names.sh,
then retry "make", nothing will happen, because
  1. err-names.c does not depend on mk-err-names.sh,
  2. The "test -f $@ || ..." idiom will not rerun mk-err-names.sh.
I would recommend to use the well-tested idiom for generated files, like in
modules/unistd and many other places.

Also, the rule does not work in VPATH builds where $(srcdir) != ".".

> err-names.h : mk-err-names.sh $(EXE).c
>   CC="$(CC)" $(SHELL) mk-err-names.sh

$(EXE) is undefined.

Bruno
-- 
In memoriam Maximilian Kolbe 

Re: canonicalize_file_name should support win32 shortcuts

[Bruno Haible]

Sam Steingold wrote:
> > The feature request is a bit odd, because it mixes the notion of
> > "native Windows" and Cygwin. Cygwin is a platform that runs inside Windows.
> > When you build mingw programs, and redistribute them, they are meant to
> > run in a native Windows environment, in which no Cygwin symlinks exist.
> 
> I have not seen a windows machine without cygwin for longer than it
> took me to install it.
> CLISP understands those "/cygdrive/c/autoexec.bat" pathnames just
> fine, and understanding symlinks is just another step forward.
> 
> > Other non-Cygwin applications don't understand Cygwin symlinks either.
> 
> Emacs understands the cygdrive pathnames and I am sure it will
> appreciate an opportunity to understand symlinks as well.

Jim, are you in favour or against adding support for Cygwin symlinks to
the 'canonicalize' module? It may also require us to split 'lstat' into
two modules: 'lstat', under GPL, with this support, and 'lstat-lgpl',
without it.

Sam, if 'canonicalize' gets this support, would you be willing to use
'canonicalize' instead of 'canonicalize-lgpl' in clisp?

Bruno
-- 
In memoriam Maximilian Kolbe 

Re: errno --> errno name ?

[Bruce Korb]

On 08/14/11 03:35, Bruno Haible wrote:

Does the .h file need to be generated? It is much more convenient to
rely on a .h file that is platform independent.


The formatting string depends upon the maximum errno name length.
If one can presume 16, then there's no need  It seems to be 15
on Linux:

   93 (EPROTONOSUPPORT) == Protocol not supported
   94 (ESOCKTNOSUPPORT) == Socket type not supported
  131 (ENOTRECOVERABLE) == State not recoverable



Also, the rule is not very robust and lacks dependencies: If one some
platform, the generation of the file fails, then you change mk-err-names.sh,
then retry "make", nothing will happen, because
   1. err-names.c does not depend on mk-err-names.sh,


It depends upon the .h and the .h depends on the script.


   2. The "test -f $@ || ..." idiom will not rerun mk-err-names.sh.


Nope.  It gets re-run in the make of err-names.h.
This idiom will cause the script to run only if there is some
way that the .c rule fires after the .h rule.  The .h rule is the real rule.


Makefile.am:
GEN_ERRNO_FILES = err-names.c err-names.h
BUILT_SOURCES  += $(GEN_ERRNO_FILES)
MOSTLYCLEANFILES   += $(GEN_ERRNO_FILES)
nodist_include_HEADERS += err-names.h
ENV_FOR_ERRNO   = CC="$(CC) $(AM_CPPFLAGS) $(CPPFLAGS)" \
srcdir="$(srcdir)"

err-names.c : err-names.h
@test -f $@ || $(ENV_FOR_ERRNO) $(SHELL) mk-err-names.sh

err-names.h : mk-err-names.sh
$(ENV_FOR_ERRNO) $(SHELL) mk-err-names.sh



I would recommend to use the well-tested idiom for generated files, like in
modules/unistd and many other places.


Please feel free to tweak it.  I think that might be easier than
seeing if I get exactly what you mean, retrying and cycling again.


Also, the rule does not work in VPATH builds where $(srcdir) != ".".


Okay, need to pass through CC and srcdir both.  See above.  Note also
that by changing the script so that the files get created in the
source directory, you also make it possible to fail because the source
directory isn't necessarily writable.  I think the source ought
to be generated in the "build" directory.  I don't exactly see how
the VPATH build fails.  Build directory sources should be found,
even in VPATH builds.


err-names.h : mk-err-names.sh $(EXE).c
CC="$(CC)" $(SHELL) mk-err-names.sh


$(EXE) is undefined.


:)  cut-n-paste error.


errno.txz
Description: application/xz-compressed-tar

Re: [PATCH] bootstrap: obey --no-git.

[Jim Meyering]

Paul Eggert wrote:
> On 08/13/2011 03:17 PM, Bruno Haible wrote:
>> Jim, Eric, Paul, you are the maintainers of 'bootstrap'. Any objection
>> against James' patch [1]?
>
> No, it looks OK to me; please apply.  If we run into problems
> we can fix them later.

I agree.
Sorry the patch languished for so long.

Re: make -q and maintainer-makefile issues?

[Paul Eggert]

On 08/14/2011 03:19 AM, Bruno Haible wrote:
> I wouldn't want to kill all
> phony targets from all Makefiles, just for "make -q".

Sorry, I see that I wasn't clear earlier.  Not all phony targets have
the problem.  For example, the following works fine:

.PHONY: all

all: foo

foo: /etc/motd
cat /etc/motd >$@

The problem occurs only when a phony target has a nonempty action,
and when "make -q" depends on the phony target.

If you can program a sanity check this way:

sanity:
@$(SANITY)

where SANITY expands to the empty string if the check succeeds,
and to 'false' if it fails, then 'make -q' should work.  This is
true regardless of whether 'sanity' is phony.

Re: freebsd 8.2 test failure: test-file-has-acl.sh

[Bruno Haible]

Jim Meyering wrote in
:
> I built the very latest
> coreutils/gnulib on a FreeBSD 8.2-RELEASE system.  All tests passed
> except this one from gnulib:
> 
> FAIL: test-file-has-acl.sh (exit: 1)
> 
> 
> + test 1 = 0
> + func_tmpdir
> + : /tmp
> + tmp=/tmp/gla57AHN
> + test -n /tmp/gla57AHN
> + test -d /tmp/gla57AHN
> + pwd
> + builddir=/u/guest/meyering/coreutils-8.12.80-82db7b/gnulib-tests
> + cd /u/guest/meyering/coreutils-8.12.80-82db7b/gnulib-tests
> + cd /tmp/gla57AHN
> + rm -f 'tmpfile[0-9]' tmp.err
> + echo 'Simple contents'
> + chmod 600 tmpfile0
> + acl_flavor=none
> + acl_flavor=freebsd
> + acl_ls_option=-ld
> + func_test_has_acl tmpfile0 no
> + func_test_file_has_acl tmpfile0 no
> + /u/guest/meyering/coreutils-8.12.80-82db7b/gnulib-tests/test-file-has-acl 
> tmpfile0
> + res=no
> + test no = no
> + /bin/ls -ld tmpfile0
> + sed 1q
> + test no = no
> + mkdir tmpdir0
> + func_test_has_acl tmpdir0 no
> + func_test_file_has_acl tmpdir0 no
> + /u/guest/meyering/coreutils-8.12.80-82db7b/gnulib-tests/test-file-has-acl 
> tmpdir0
> + res=no
> + test no = no
> + /bin/ls -ld tmpdir0
> + sed 1q
> + test no = no
> + test freebsd != none
> + test -f /usr/xpg4/bin/id
> + ID=id
> + id -u
> + myuid=14263
> + id -g
> + mygid=14263
> + auid=1
> + test 1 = 14263
> + agid=1
> + test 1 = 14263
> + setfacl -m user:1:1 tmpfile0
> setfacl: tmpfile0: acl_get_file() failed: Operation not supported
> + func_test_has_acl tmpfile0 yes
> + func_test_file_has_acl tmpfile0 yes
> + /u/guest/meyering/coreutils-8.12.80-82db7b/gnulib-tests/test-file-has-acl 
> tmpfile0
> + res=no
> + test no = yes
> + echo 'file_has_acl("tmpfile0") returned no, expected yes'
> file_has_acl("tmpfile0") returned no, expected yes
> + exit 1
> + exit 1

The test works fine in earlier versions of FreeBSD.

In order to debug this, I would need ssh access to a box running FreeBSD 8.2.
I tried to install FreeBSD 8.2 in VirtualBox for 3 hours, without success.

Bruno
-- 
In memoriam Maximilian Kolbe 

Re: errno --> errno name ?

[Bruno Haible]

Bruce Korb wrote:
> > Does the .h file need to be generated? It is much more convenient to
> > rely on a .h file that is platform independent.
> 
> The formatting string depends upon the maximum errno name length.
> If one can presume 16, then there's no need  It seems to be 15
> on Linux:

Then, I would
  1. define the macro with value 15 in the .h file,
  2. document that this value may be increased in future versions,
  3. add a warning to the mk-err-names.sh script when an error name
 is encountered on some platform that is longer than 15 columns.

By the way, instead of defining a macro ERRNO_DISPLAY_FMT (that ends with
a newline - why?), it is more general to define a macro
  #define MAX_ERROR_NAME_LENGTH 15
Users who want to user columns can then do things like
  printf ("%.*s", MAX_ERROR_NAME_LENGTH + 1, ...)

> > then retry "make", nothing will happen, because
> >1. err-names.c does not depend on mk-err-names.sh,
> 
> It depends upon the .h and the .h depends on the script.

Ah, ok, sorry. I was looking at one rule only.

> Please feel free to tweak it.  I think that might be easier than
> seeing if I get exactly what you mean, retrying and cycling again.

But through this process of proposing, retrying, and listening to comments
you (and others who read the mailing list) learn about the technique how
to design a usable, generic, and at the same time practical API; about the
considerations specific to gnulib; about the things to remember regarding
VPATH; and so on.

> > Also, the rule does not work in VPATH builds where $(srcdir) != ".".
> 
> Okay, need to pass through CC and srcdir both.  See above.  Note also
> that by changing the script so that the files get created in the
> source directory, you also make it possible to fail because the source
> directory isn't necessarily writable. I think the source ought
> to be generated in the "build" directory.

Yes, you are right, the $(srcdir) may be read-only. Actually Automake's
"make distcheck" rule verifies that you aren't writing into $(srcdir)
if $(srcdir) != ".". -- I didn't suggest to generate the files in
$(srcdir). All I said was that the Makefile rules would fail in the VPATH
case.

> I don't exactly see how the VPATH build fails.

It will not find the mk-err-names.sh script in the first place. The Makefile
rules are executed in the build directory.

Please, that's part of submitting a gnulib module: adding it to your
gnulib working directory, doing "./gnulib-tool --create-testdir ..." of it,
and optionally testing this testdir with "mkdir b; cd b; ../configure; make".

Bruno
-- 
In memoriam Maximilian Kolbe 

Re: errno --> errno name ?

[Bruce Korb]

Hi Bruno,

On 08/14/11 10:25, Bruno Haible wrote:

By the way, instead of defining a macro ERRNO_DISPLAY_FMT (that ends with
a newline - why?), it is more general to define a macro
   #define MAX_ERROR_NAME_LENGTH 15
Users who want to user columns can then do things like
   printf ("%.*s", MAX_ERROR_NAME_LENGTH + 1, ...)


"%-.*s", no?  Anyway, that is better.  There's enough to printf
that even after all these years, it isn't all at the tips of my fingers:)
Maybe it's *because* of all the years, I learned it in a predecessor
form and haven't gone back to learn all of what featuritis did to it. :-D


Please feel free to tweak it.  I think that might be easier than
seeing if I get exactly what you mean, retrying and cycling again.


But through this process of proposing, retrying, and listening to comments


Sure.  It depends somewhat on your (and others') patience, too.
This is kind-of a play time activity.  My focus this weekend is
actually deferred tax returns (due Monday night because I had
this employer who misrepresented my earnings and .)
The next two weekends are booked, then I go to Europe for a couple
of weeks and when I get back I suspect there will be some chores
around the house.  In other words, it might be a bit like the
libposix stuff.  With another hand, it goes faster.


It will not find the mk-err-names.sh script in the first place. The Makefile
rules are executed in the build directory.


OK, the invocation has to have a "where is it?" search.


Please, that's part of submitting a gnulib module: adding it to your
gnulib working directory, doing "./gnulib-tool --create-testdir ..." of it,
and optionally testing this testdir with "mkdir b; cd b; ../configure; make".


Whenever I have both time and inclination (a roundtuit).  Maybe this fall,
unless someone out there wants to play, too.

Cheers - Bruce

Re: canonicalize_file_name should support win32 shortcuts

[Sam Steingold]

On Sun, Aug 14, 2011 at 8:51 AM, Bruno Haible  wrote:
>
> Sam, if 'canonicalize' gets this support, would you be willing to use
> 'canonicalize' instead of 'canonicalize-lgpl' in clisp?

yes.

-- 
Sam Steingold 

I fixed this once already [Was Re: [PATCH] bootstrap: obey --no-git.]

[Gary V. Vaughan]

Hi All,

On 14 Aug 2011, at 05:45, Paul Eggert wrote:
> On 08/13/2011 03:17 PM, Bruno Haible wrote:
>> Jim, Eric, Paul, you are the maintainers of 'bootstrap'. Any objection
>> against James' patch [1]?
> 
> No, it looks OK to me; please apply.  If we run into problems
> we can fix them later.

Is my complete rewrite of bootstrap (which already has what appears
to be an earlier name for the same option, `--skip-git', at Eric's
request) unsuitable?

No disrespect to the incumbent script, which by Paul's own admission
sort of grew organically in a few projects which eventually accreted
in gnulib, but my rewrite was quite carefully designed and written
specifically to be maintainable, extensible and understandable.

And it runs over 30% faster than the current version (last I checked -
if the slurp function has been removed from gnulib's existing
bootstrap, then mine probably lost most of its edge in execution time).

And it successfully uses my M4 based method of extracting various
filenames and directory paths from configure.ac, which obvious works
far more reliably than sed. I'd like to see libtoolize and
autoreconf and others adopt this method so that we can use macro
expansions and whatever quoting we need without worrying about
the current tools choking in sed expressions.

And it is very well commented, now with a good first draft texinfo
chapter for @including into the gnulib documentation.

No organic accretion here.

I'm attaching the latest version, along with the texinfo documentation
in hope of consideration for adoption into gnulib so that people other
than me can benefit.

Please tell me to stop bugging the list if you're tired of my
mentioning this from time to time. On the other hand, if you just
need more proof that this one is working as well as I say, I'll add
it on a topic branch to the gnulib using projects I have commit
rights to, and update the bootstrap.confs I wrote for them last
year provided someone will take a look afterwards, with the intention
of agreeing to supercede the existing bootstrap if everything works
as advertised.

I feel a bit like the elephant in the room...

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


bootstrap.tar.bz2
Description: BZip2 compressed data

Re: I fixed this once already [Was Re: [PATCH] bootstrap: obey --no-git.]

[Paul Eggert]

On 08/14/2011 01:38 PM, Gary V. Vaughan wrote:
> Please tell me to stop bugging the list if you're tired of my
> mentioning this from time to time. On the other hand, if you just
> need more proof that this one is working as well as I say, I'll add
> it on a topic branch to the gnulib using projects I have commit
> rights to, and update the bootstrap.confs I wrote for them last
> year provided someone will take a look afterwards, with the intention
> of agreeing to supercede the existing bootstrap if everything works
> as advertised.

I haven't had time to look at the complete rewrite, but I think
this is a good way to proceed.  I don't recall which projects
you were doing.  I could also try it out with a smaller project
that isn't near a release (diffutils comes to mind ...).

Re: make -q and maintainer-makefile issues?

[Bruno Haible]

Paul Eggert wrote:
> > I wouldn't want to kill all
> > phony targets from all Makefiles, just for "make -q".
> 
> Sorry, I see that I wasn't clear earlier.  Not all phony targets have
> the problem.  For example, the following works fine:
> 
> .PHONY: all
> 
> all: foo
> 
> foo: /etc/motd
>   cat /etc/motd >$@
> 
> The problem occurs only when a phony target has a nonempty action,
> and when "make -q" depends on the phony target.

Thanks for explaining. But I'm still not sure I understand. What is
the difference between your test case

-
all: foo
foo: /etc/motd
cat /etc/motd >$@
-

and the snippet from modules/relocatable-prog

---
uninstall-hook: uninstall-relocwrapper
uninstall-relocwrapper:
some-statements;
---

and the pattern from po/Makefile.in.in:

-
all : sanity
all : foo
sanity :
@test `expr 1 + 1` = 2
foo :
echo > foo
-

The target has non-empty statements in each case.

> If you can program a sanity check this way:
> 
> sanity:
>   @$(SANITY)
> 
> where SANITY expands to the empty string if the check succeeds,
> and to 'false' if it fails, then 'make -q' should work.  This is
> true regardless of whether 'sanity' is phony.

An interesting idea. But in the special case of po/Makefile.in.in
I cannot use it, without making use of GNU make $(...) function call
expressions.

Bruno
-- 
In memoriam Maximilian Kolbe 

Re: I fixed this once already [Was Re: [PATCH] bootstrap: obey --no-git.]

[Gary V. Vaughan]

Hi Paul,

On 15 Aug 2011, at 04:19, Paul Eggert wrote:
> On 08/14/2011 01:38 PM, Gary V. Vaughan wrote:
>> Please tell me to stop bugging the list if you're tired of my
>> mentioning this from time to time. On the other hand, if you just
>> need more proof that this one is working as well as I say, I'll add
>> it on a topic branch to the gnulib using projects I have commit
>> rights to, and update the bootstrap.confs I wrote for them last
>> year provided someone will take a look afterwards, with the intention
>> of agreeing to supercede the existing bootstrap if everything works
>> as advertised.
> 
> I haven't had time to look at the complete rewrite, but I think
> this is a good way to proceed.  I don't recall which projects
> you were doing.

Great! Thank you :)

Here's what I have so far:

 * g...@github.com:gvvaughan/GNU-bison.git in gary/bootstrap
   https://github.com/gvvaughan/GNU-bison/commits/gary/bootstrap

   The bison bootstrap is very straight-forward, so I just redid
   it with my new bootstrap script in the gary/bootstrap branch. I
   don't have a commit bit for bison, so I've put a mirror with
   my branch in it up on github, per the header to this bullet.

 * g...@github.com:gvvaughan/GNU-coreutils.git in gary/bootstrap
   https://github.com/gvvaughan/GNU-coreutils/commits/gary/bootstrap

   I can't get the currently checked in bootstrap to finish running
   on current master, which makes porting it's contents into the
   new bootstrap.conf futile for me. Instead I've updated to the new
   bootstrap script on the original branch I made when I was writing
   it, and pushed a mirror to github here too. (Note that I was having
problems compiling sort just after threads had been added around
   that time, but a `make -k' completes on my Mac OS 10.7 machine.)

   This one is interesting because it uses gettext and also has a
   fairly torturous bootstrap process.  I wasn't able to eliminate
   slurp entirely, but there is only something much much smaller and
   possible to understand remaining in bootstrap.conf.

 * g...@github.com:gvvaughan/GNU-libtool.git in topic/use-gnulib
   https://github.com/gvvaughan/GNU-libtool/commits/topic/use-gnulib

   I'm not ready to push my working branches up to savannah yet, since
   I might want to rebase them locally first.  So I've put a mirror up
   in my github account for you to try out.

   This one is interesting, because Libtool uses a complicated bootstrap
   process, with several subprojects to autoconfiscate, and additional
   options to bootstrap itself added using the extension mechanisms alone.
   You'll notice in configure.ac that there's a good deal of mucking
   about with M4 macros around the values that bootstrap is still
   extracting quite successfully.

 * g...@github.com:gvvaughan/GNU-m4.git in gary/bootstrap
   https://github.com/gvvaughan/GNU-m4/commits/gary/bootstrap

   Again, I've mirrored some private branches that are subject to
   rebasing before merging and committing back to the savannah repo
   so that you can see what is going on here. But, I have rebased this
   on onto the HEAD of branch-1.4, with the latest gnulib in a submodule.
   I haven't updated the other branches yet (branch-1.6 and master), but
   that will happen automatically once gnulib is presenting the new
   bootstrap script.

   M4 is interesting because it uses "the other" methodology of treating
   gnulib-cache.m4 as truth and checking it in, with bootstrap managing
   it rather than creating it.  And it uses git-version-gen to generate
   its version number on the fly, which bootstrap copes with quite easily.
   You can also try out the --skip-git and skip-po options here. The new
   bootstrap script started life because the current one has (had?) a
   few incongruencies that prevented it working in sympathy with how Eric
   and I manage M4 development.

 * git://git.savannah.gnu.org/zile.git in topic/sane-bootstrap
   http://git.savannah.gnu.org/cgit/zile.git/log/?h=topic/sane-bootstrap

   This branch (with my bootstrap script in it) has already been merged
   to master and lua branches, both of which demonstrate very different
   bootstraps (especially lua, which has no compiled code in it at all!).

 * It seems I also made a start at converting GNU tar to my new bootstrap,
   but I came unstuck when porting the copy_files function out of the
   existing bootstrap into a new bootstrap.conf.  I don't really have time
   to finish it now, but I hope the other projects above give you enough
   confidence to adopt the new script directly into gnulib for propagation
   into other projects, without me needing to finish the GNU tar conversion
   on my own first?

> I could also try it out with a smaller project
> that isn't near a release (diffutils comes to mind ...).

Please do, that would be awesome.  The documentation is in the tarball
attached earlier in the thread, I didn't bother to add another copy to
every repo above... although the script is w

Re: make -q and maintainer-makefile issues?

[Paul Eggert]

On 08/14/2011 03:50 PM, Bruno Haible wrote:
> What is the difference between your test case
> 
> -
> all: foo
> foo: /etc/motd
>   cat /etc/motd >$@
> -
> 
> and the snippet from modules/relocatable-prog
> 
> ---
> uninstall-hook: uninstall-relocwrapper
> uninstall-relocwrapper:
>   some-statements;
> ---

My test case creates the file 'foo', but the snippet does not create a
file 'uninstall-relocwrapper'.

> and the pattern from po/Makefile.in.in:
> 
> -
> all : sanity
> all : foo
> sanity :
>   @test `expr 1 + 1` = 2
> foo :
>   echo > foo
> -

Similarly, my test case creates a file 'foo', but the 'sanity' rule
does not create a file 'sanity'.

>> If you can program a sanity check this way:
>>
>> sanity:
>>  @$(SANITY)
>>
>> where SANITY expands to the empty string if the check succeeds,
>> and to 'false' if it fails, then 'make -q' should work.  This is
>> true regardless of whether 'sanity' is phony.
> 
> An interesting idea. But in the special case of po/Makefile.in.in
> I cannot use it, without making use of GNU make $(...) function call
> expressions.

Can the sanity check be expressed as an Automake conditional?
That might do the trick.  (On the other hand, does gnulib
require Automake?)

Another possibility is to use a prefix +, like this:

all: sanity foo
sanity:
+@test `expr 1 + 1` = 2
foo:
touch $@

The '+' feature is something I wasn't aware of until just now.  It is
standardized by POSIX, but was not in Unix version 7.  I don't know
how portable it is in practice; I wouldn't recommend it unless we do
reasonably-extensive portability testing.  (It is not suitable for all
sanity checks; just for side-effect-free checks that do not depend on
anything other than other sanity checks.)

All in all, the approach taken in the gnulib now may be more
straightforward and portable than these alternatives.