bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mingw test cleanups


From: Eric Blake
Subject: Re: mingw test cleanups
Date: Sun, 06 Sep 2009 13:28:19 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Bruno Haible on 9/6/2009 11:27 AM:
>> $ cross_compiling=yes gl_cv_func_open_slash=no CC='gcc -mno-cygwin' \
>>    CFLAGS='-Wall -gdwarf-2' ./gnulib-tool --with-tests --test canonicalize
>> ...
>> for the situation where AC_CANONICAL_HOST is mis-detected as cygwin rather 
>> than 
>> mingw (as in my above gnulib-tool command line) ...
> 
> The arguments that you are passing to 'configure' here are invalid.

Yes, I'm well aware of creating an independent testdir and using a proper
cross-compilation environment when things really matter.  But my shortcut
is generally adequate enough to shave time and limp by with a single step
instead of two (it is already time-consuming enough to use gnulib-tool on
cygwin, due to slow forks).

>> --- a/lib/chown.c
>> +++ b/lib/chown.c
>> +#else /* !HAVE_CHOWN */
>> +  errno = EOPNOTSUPP;
>> +  return -1;
>> +#endif
>>  }
>> --- a/lib/lchown.c
>> +++ b/lib/lchown.c
>> +#else /* !HAVE_CHOWN */
>> +  errno = EOPNOTSUPP;
>> +  return -1;
>> +#endif
>>  }
> 
> EOPNOTSUPP is an error code related to sockets. I also see it sometimes on
> NFS mounts. POSIX [1] describes it as "Operation not supported on socket".
> Probably ENOSYS ("Function not supported.") is a better error code.

ENOSYS does make more sense (even though POSIX allows ENOSYS and
EOPNOTSUPP to be equal, it does not require it).  You're welcome to make
that change, if I don't get to it first.

> 
>> --- a/modules/canonicalize-lgpl-tests
>> +++ b/modules/canonicalize-lgpl-tests
>> @@ -5,9 +5,12 @@ tests/test-canonicalize-lgpl.c
>>  Depends-on:
>>
>>  configure.ac:
>> +AC_CHECK_FUNCS_ONCE([symlink])
>> +HAVE_SYMLINK=ac_cv_func_symlink
>> +AC_SUBST([HAVE_SYMLINK])
>> diff --git a/modules/canonicalize-tests b/modules/canonicalize-tests
>> index 875984e..092b9ef 100644
>> --- a/modules/canonicalize-tests
>> +++ b/modules/canonicalize-tests
>> @@ -5,9 +5,12 @@ tests/test-canonicalize.c
>>  Depends-on:
>>
>>  configure.ac:
>> +AC_CHECK_FUNCS_ONCE([symlink])
>> +HAVE_SYMLINK=ac_cv_func_symlink
>> +AC_SUBST([HAVE_SYMLINK])
> 
> Setting the value of the same variable in two different configure.ac snippets
> is going to break the next time someone will modify one of the two files but
> forget about the other one. If you cannot move these to a common .m4 file,
> I would use two different variable names, instead of 2x HAVE_SYMLINK.

Yes, I could see the benefit of refactoring m4/readlink.m4 to make it
easier to call just a detection portion from other modules without having
to depend on the readlink module and compile readlink.c, as well as the
creation of m4/symlink.m4 to do likewise.  In fact, it probably makes
sense to consolidate on a single witness - mingw doesn't support either
symlink or readlink, but gnulib provides a readlink replacement, so is it
better to use HAVE_SYMLINK or HAVE_READLINK as the witness that symlinks work?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqkDVMACgkQ84KuGfSFAYBWowCgo99U2WiZfhGqwrLSLI/a+AWc
X8QAnRpSSNchmmQ+zH/3289cybnrbzeg
=SAw6
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]