bug#29376: automake gnits version check vs. gnulib's git-version-gen?

2017-11-20 Thread Bernhard Voelker
At GNU findutils, we're trying to use gnulib's git-version-gen [1] to derive the version string from the current git commit. Until now, we've been using a 3-level versioning scheme X.Y.Z, e.g. the latest tag was 'v4.6.0'. Now for any non-release commit version before the next release,

Re: Finding #includes from a yacc .y.

2017-11-20 Thread Nick Bowler
Hi Ralph, On 2017-11-20, Ralph Corderoy wrote: >> It seems wrong for foo.y to have to `#include >> "path/from/root/to/bar.h" since that means it has to alter if they >> move around the hierarchy. Is there another way? > > I can be more precise having dug into this project

Re: Finding #includes from a yacc .y.

2017-11-20 Thread Ralph Corderoy
More noise... > It works in this one case, but I know that doesn't necessarily mean > it's right. :-) I've found AM_CPPFLAGS in `info automake | less' and I think that's answering it. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

Re: Finding #includes from a yacc .y.

2017-11-20 Thread Ralph Corderoy
Hi again, > It seems wrong for foo.y to have to `#include > "path/from/root/to/bar.h" since that means it has to alter if they > move around the hierarchy. Is there another way? I can be more precise having dug into this project a bit. Currently, it has sbr_libmh_a_CPPFLAGS =

Finding #includes from a yacc .y.

2017-11-20 Thread Ralph Corderoy
Hi, In a subdirectory, a foo.y gets turned into a foo.c. Both thus `#include "bar.h"' that sits alongside them. This all works fine. But use a build directory, i.e. run configure from somewhere other than `.', and foo.c fails to build because bar.h isn't found. (A similar problem happens with

Re: warning: TEST_LDFLAGS' is defined but no program or library has 'TEST' as canonical name

2017-11-20 Thread Thomas Martitz
Am 20.11.2017 um 19:01 schrieb Nick Bowler: Hi, If you were to later add a program called TEST, then the results could be surprising. But you can certainly ignore the warning if you'd like. I understand that, however we're extremely unlikely to build programs named in all-upper case.

Re: warning: TEST_LDFLAGS' is defined but no program or library has 'TEST' as canonical name

2017-11-20 Thread Nick Bowler
Hi, On 2017-11-20, Thomas Martitz wrote: > here's some quite annoying warning. I'm trying to define a variable > TEST_LDFLAGS that multiple programs use. There is no program named TEST. > The same works fine with TEST_CFLAGS (i.e. no warning is displayed). > > Here's the

warning: TEST_LDFLAGS' is defined but no program or library has 'TEST' as canonical name

2017-11-20 Thread Thomas Martitz
Hello, here's some quite annoying warning. I'm trying to define a variable TEST_LDFLAGS that multiple programs use. There is no program named TEST. The same works fine with TEST_CFLAGS (i.e. no warning is displayed). Here's the warning: Makefile.am:4: warning: variable 'TEST_LDFLAGS' is