Re: parse-datetime.c generated in the source (instead of build) directory

2018-03-16 Thread Bruno Haible
Kamil Dudka wrote: > parse-datetime.c generated out of parse-datetime.y ends up in the source > directory, instead of the build directory as one would expect. This was > introduced by the following commit: > > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6c680191 > > Neither

Re: parse-datetime.c generated in the source (instead of build) directory

2018-03-16 Thread Paul Eggert
Kamil Dudka wrote: the build should work even if the source directory is on a read-only file system. That's the first I've heard of that constraint, at least for the case where one is building from the Git repository. (The problem you describe should not occur when building from a distributio

Re: parse-datetime.c generated in the source (instead of build) directory

2018-03-16 Thread Vivien Kraus
Sorry, I have just checked and automake does not distribute the generated source by default, thus the modified .y.c rule is required. Le vendredi 16 mars 2018 à 19:09 +0100, Vivien Kraus a écrit : > Hello, > > Distributing the generated sources is the default behaviour to expect > from automake;

Re: parse-datetime.c generated in the source (instead of build) directory

2018-03-16 Thread Vivien Kraus
Hello, Distributing the generated sources is the default behaviour to expect from automake; I don't really understand why it is needed to override the .y.c rule... This behaviour permits you to configure, build, install, check... the package without having bison installed. Since the generated .c

parse-datetime.c generated in the source (instead of build) directory

2018-03-16 Thread Kamil Dudka
parse-datetime.c generated out of parse-datetime.y ends up in the source directory, instead of the build directory as one would expect. This was introduced by the following commit: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6c680191 Neither the comment, nor the change log

Re: glob on glibc systems

2018-03-16 Thread Bruno Haible
I wrote: > This is because /usr/include/gnu-versions.h now defines > _GNU_GLOB_INTERFACE_VERSION to 2, following this commit in glibc: > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=ccf970c7a77e86f4f5ef8ecc5e637114b1c0136a The motivation of _GNU_GLOB_INTERFACE_VERSION == 2 being the new

glob: fix for mingw

2018-03-16 Thread Bruno Haible
$ ./gnulib-tool --create-testdir --dir=../testdir-glob --single-configure --with-c++-tests glob produces a testdir that, when compiled on mingw, produces a link error: undefined reference to `lstat' This fixes it. 2018-03-16 Bruno Haible glob: Fix link error on native Windows.

glob: fix failure in C++ mode

2018-03-16 Thread Bruno Haible
$ ./gnulib-tool --create-testdir --dir=../testdir-glob --single-configure --with-c++-tests glob produces a testdir that, when compiled on a glibc 2.23 system, produces errors: depbase=`echo test-glob-c++.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ g++ -DHAVE_CONFIG_H -I. -I.. -DGNULIB_STRICT_CHECKIN

host-cpu-c-abi: Support for RISC-V CPU

2018-03-16 Thread Bruno Haible
2018-03-15 Bruno Haible host-cpu-c-abi: Support for RISC-V CPU. * m4/host-cpu-c-abi.m4 (gl_HOST_CPU_C_ABI): Recognize the various riscv32 and riscv64 ABIs. References: https://github.com/riscv/riscv-toolchain-conventions https://gcc.gnu.org/online