[PATCH weston] build: Define wayland prereq version

[Emil Velikov]

On 20 May 2016 at 21:35, Bryce Harrington <bryce at osg.samsung.com> wrote:
> On Thu, May 12, 2016 at 09:48:17AM +0100, Emil Velikov wrote:
>> On 12 May 2016 at 09:13, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> > On Thu, 12 May 2016 11:12:28 +1000
>> > Peter Hutterer <peter.hutterer at who-t.net> wrote:
>> >
>> >> On Wed, May 11, 2016 at 01:18:59PM -0700, Bryce Harrington wrote:
>> >> > Establishes a single variable for defining the libwayland version
>> >> > requirements.  Enforces the same version dependency between
>> >> > libwayland-client and libwayland-server, as recommended by pq in the
>> >> > 1.11 release discussions.
>> >> >
>> >> > Signed-off-by: Bryce Harrington <bryce at osg.samsung.com>
>> >> > ---
>> >> >  configure.ac | 12 +++++++-----
>> >> >  1 file changed, 7 insertions(+), 5 deletions(-)
>> >> >
>> >> > diff --git a/configure.ac b/configure.ac
>> >> > index 2ca1f4e..0b23fc4 100644
>> >> > --- a/configure.ac
>> >> > +++ b/configure.ac
>> >> > @@ -4,6 +4,8 @@ m4_define([weston_micro_version], [91])
>> >> >  m4_define([weston_version],
>> >> >            [weston_major_version.weston_minor_version.weston_micro_version])
>> >> >
>> >> > +m4_define([WAYLAND_PREREQ_VERSION], "1.10.0")
>> >>
>> >> how comes the line above uses [] and here you use ""? is that intentional?
>> >> (I keep forgetting whether there's a difference between the two in m4)
>> >
>> > Yeah, I'm not that sure about using a m4 define. It is one way to do
>> > it, but the quotes do look suspicious.
>> >
>> > FWIW, Mesa uses a big list of common dependency variables too, maybe
>> > copy that approach?
>> >
>> > CC'ing Quentin and Emil, they probably know what's good.
>> >
>> In all honesty I don't know which one is better, so any
>> info/references will be appreciated. For the time being (personally)
>> I'd stick with the following as it reads a bit easier ;-)
>>
>> WAYLAND_PREREQ_VERSION="1.10.0"
>
> Alright, so I've tested several different variations.  I've tested both
> using version 1.10.0 (which must pass), and 1.99.0 (which must fail)
>
>                                                N=10  N=99
> m4_define([WAYLAND_PREREQ_VERSION], "1.N.0")   PASS  FAIL  --> Okay
> m4_define([WAYLAND_PREREQ_VERSION], [1.N.0])   PASS  FAIL  --> Okay
> m4_define([WAYLAND_PREREQ_VERSION], 1.N.0)     PASS  FAIL  --> Okay
>
> WAYLAND_PREREQ_VERSION="1.N.0"                 PASS  PASS  --> Incorrect
> WAYLAND_PREREQ_VERSION=1.N.0                   PASS  PASS  --> Incorrect
> WAYLAND_PREREQ_VERSION=[1.N.0]                 PASS  PASS  --> Incorrect
>
> In all cases, I've referenced the variable as just
> WAYLAND_PREREQ_VERSION in the code.  If I reference it as
> $WAYLAND_PREREQ_VERSION then autogen.sh errors indicating a blank string
> was substituted.  E.g.:
>
>   configure: error: Package requirements (wayland-server >=  pixman-1 >= 0.25.2 xkbcommon >= 0.3.0) were not met:
>   No package '>=' found
>   No package '0.25.2' found
>
Hmm that doesn't sounds right.

The following simplified example works like a charm - change FOO_REQ
(or BAR version) to 0.20 and observe the result (expected failure).
And yes, the approach does work in for more complex configure.ac -
just tested xserver, mesa and libdrm.

$ cat Makefile.am

$ cat configure.ac
AC_PREREQ([2.63])
AC_INIT([libfoo], [0.0.1])

AM_INIT_AUTOMAKE([1.10 foreign])

LT_PREREQ([2.2])
LT_INIT([disable-static])

FOO_REQ=0.10
PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= $FOO_REQ])

BAR="pciaccess >= 0.20"
dnl You can put the square brackets around $BAR. Personally I'm not a fan
PKG_CHECK_MODULES(PCIACCESS, $BAR)

AC_CONFIG_FILES([Makefile])


> I'd tested a number of other variations prior to settling on the
> m4_define() syntax, which is why I'm leaning that direction - I just
> couldn't get anything else to work.  So if anyone feels m4_define() to
> be the wrong way to do it, I'm happy to try another way but will need
> more specific direction.
>
Do you have the patch somewhere ? Without it no one can tell you
what's going wrong.
I'm leaning that there's a trivial mistake in it somewhere. Or perhaps
there's something fishy in the existing configure.ac ?

-Emil