Re: Gnulib in non-Autotools projects with --create-testdir

[Bruno Haible]

Hi John,

> I'm working on a project that uses the Meson build system. I'd like to use 
> the 
> uname module on MinGW-w64

Interesting. Once you have a recipe that works, we could add it to the Gnulib
documentation.

> so I consulted a relevant discussion about Gnulib 
> with CMake [1]:
> 
> >> But gnulib-tool by design creates a subdirectory, and you can yourself add
> >> a simple configure.ac to that subdirectory, as outlined in the 
> >> documentation
> > When I needed it 10 years ago, I was able to get around this limitation by 
> > using the --create-testdir option of gnulib-tool.  It created a directory
> > with configure script that (after running make) produced a static library.
> > I am not sure if this approach had any side effects, like turning on debug 
> > build, but I was at least not forced to create configure.ac etc.
> 
> This got me on the right track. With
>     gnulib-tool --without-tests --conditional-dependencies --create-testdir \
>     --dir foo uname

Yes, that's the idea explained in [1].

> I can run configure and Make to build gllib/libgnu.a
> 
> I'm not sure how to use it though. I tried this:
> $ x86_64-w64-mingw32-gcc bar.c -Ifoo/gllib foo/gllib/libgnu.a
> In file included from uname.c:9:
> foo/foo/gllib/sys/utsname.h:33:16: fatal error: sys/utsname.h: No such file 
> or 
> directory
> 33 | # include_next <sys/utsname.h>
> 
> Here's what the section of that header looks like to me:
> #if 1
> 
> /* Minix 3.1.8 has a bug: <stddef.h> must be included before <sys/utsname.h>.
> But avoid namespace pollution on glibc systems.  */
> # if defined __minix && !defined __GLIBC__
> #  include <stddef.h>
> # endif
> 
> # include_next <sys/utsname.h>
> 
> #endif

This indicates that you have been generating the sys/utsname.h on a machine
that has /usr/include/sys/utsname.h (e.g. not mingw) and are now trying to
use it on mingw. It does not work this way. [2]

> I don't know how to interpret this output
> $ gnulib-tool --extract-recursive-link-directive uname
> $(GETHOSTNAME_LIB)

The config.status generated by 'configure' contains a variable substitution
for e.g. GETHOSTNAME_LIB. Its value is a set of compiler options (possibly
empty) that you need to use when linking a program or shared library
that makes use of the 'gethostname' function.

In your case, I guess the linking command is done outside of the scope
of configure. Therefore you to transport the values somehow. One way to
do so is to generate some variable list for cmake. I don't know the
syntax of variable lists in cmake. Assuming that it is the ':=' token,
the file would be called 'variables.in' and look like this:
  GETHOSTNAME_LIB := @GETHOSTNAME_LIB@
In configure.ac you would add a statement
  AC_CONFIG_FILES([variables])
This would make sure that at the end of running 'configure', a file
'variables' gets created, with the right values for the target platform.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2019-01/msg00049.html
[2] https://lists.gnu.org/archive/html/bug-gnulib/2019-01/msg00070.html