[PATCH][weston] configure.ac: Add --with-wayland-scanner-path

[Quentin Glidic]

On 7/18/17 3:58 PM, Pekka Paalanen wrote:
> On Wed, 24 May 2017 11:32:21 +0300
> Jussi Kukkonen <jussi.kukkonen at intel.com> wrote:
> 
>> On 23 May 2017 at 14:51, Quentin Glidic <sardemff7+wayland at sardemff7.net>
>> wrote:
> 
>>> So you want to break the simple (cross-compiling) cases to fix
>>> something that doesn’t need fixing?
>>
>> I think that is not warranted.
>> * My issue was that every wayland-scanner user was doing something
>> different, often in a way that required patching in Yocto
>> * Weston was fine for us but Pekka gave me feedback that lead me to
>> believe the weston method was not the best solution either
>>
>> I did my best to try and resolve both issues. It looks like my
>> attempt was not successful but there should be no reason to say I
>> "want to break" something.
> 
> Hi,
> 
> I'm with Jussi here.
> 
>>> If you want to make a patch, it should not introduce a regression.
>>
>> I think _if_ the goal is to use the same scanner lookup in e.g. mesa
>> and weston, some use case in one or the other is just bound to have a
>> regression.
> 
> Quentin, do you see any way unifying the usage of wayland-scanner
> without regressing at least one user?

Yes, we can just do what we do now in Weston, *adding* the Yocto style.
IOW, we want to support, without passing any variable:
- native and cross-compiling as a system package
   just wayland-scanner from (native) path is good
- native in a custom prefix (system may be different version)
   prefer the pkg-config file
- cross-compiling in a custom prefix (system may be different version)
   we need to check for the native (custom prefix) pkg-config here

In all three cases, checking for the version would be much better. We 
could even use the native system scanner in some cases if the version 
matches, avoiding another build in cross-compiling case.

In pseudo-code, here is what I suggest:

get_wayland_version()

# macro WL_PROG_SCANNER([version])
if $cross_compiling; then
     get_native_pkg_config_scanner_path()
else
     get_pkg_config_scanner_path()
fi
if scanner == ""; then
     get_PATH_scanner_path()
     if scanner == "" || ! check_scanner_version(); then
         error()
     fi
fi
# macro end

You can call "pkg-config --variable=wayland_scanner 'wayland-scanner = 
"version'" directly to let pkg-config do the version check.

That would support all use cases listed above, with no variable. And we 
can still add the configure switch for very specific corner cases that 
might exist.


>>> So at this point, we should make a generic patch, ideally (IMO) in
>>> wayland-scanner.m4, and have people test it in all their different
>>> setup to see if it works as expected.
> 
> Is anyone actually using wayland-scanner.m4?
> 
> I did not find any evidence of Weston using it. Certainly no-one is
> using wayland-scanner.mk anymore because of the structure or
> wayland-protocols and the need to search for XML files in both local
> and system paths. Since wayland-scanner.m4 has a reference to
> wayland-scanner.mk, I doubt anyone is using wayland-scanner.m4 either.
> 
> We should make a plan to get rid of wayland-scanner.mk and
> wayland-scanner.m4, I do not think they are fixable.

We can deprecate the current macro while adding new ones. Or have a new 
file. It doesn’t matter much, it’s just a (autoreconf) build time dep on 
the newer Wayland.
I see no issue with wayland-scanner.m4 not being used. We can make *new* 
versions use it, it’s adding API/ABI.


>>> If you’re not comfortable making one, I’ll do it by this week-end
>>> so you can test it in yours.
> 
> Did anything come out of that?

We need to agree on the “good” way to do the checks first, but if you 
feel better doing so with a real patch as a basis, I can do it.


> There is also the sysroot patch from Tomek Bury that no-one has
> commented on yet.
> https://patchwork.freedesktop.org/patch/165478/

Ack.


-- 

Quentin “Sardem FF7” Glidic