[Mesa-dev] [PATCH] configure.ac: rework wayland-protocols handling

[Emil Velikov]

On 21 July 2017 at 14:19, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi Emil,
>
> On 21 July 2017 at 14:13, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 21 July 2017 at 13:28, Daniel Stone <daniel at fooishbar.org> wrote:
>>> Why do we need to dist these files? We enforce that wayland (providing
>>> wayland-scanner) and wayland-protocols (providing the XML) are present
>>> at configure time,
>> Good point Daniel. AFAICT the general principle in Mesa has been to
>> provide all the required sources so that extra tools are not needed.
>>
>> We could lift the requirement in configure.ac, same way we do for
>> python/flex/bison. If the files are already there (aka we're using
>> release tarball) make the wayland bits a optdepend.
>
> I don't mind relaxing it, but OTOH wayland-scanner is already there
> when you install libwayland, and wayland-protocols is just a pile of
> XML. So it doesn't really seem like it should cause much pain, and the
> scanner is also very quick to execute.
>
In principle I agree, yet I've seem a handful of questionable
decisions by builders/package maintainers.

>>> so disting them doesn't seem to provide any benefit
>>> - they'll just be overwritten with the locally-generated variants. At
>>> that point, we'll also have one copy in the source directory (from
>>> dist), and another in the build directory (from local generation),
>>> which seems like a recipe for disaster.
>>>
>> The recipe for disaster part is a slight exaggeration. Plus we already
>> handle that case because people do in-tree builds :-\
>> It was addressed by my earlier suggestion to list the builddir include
>> before the srcdir one (which is in master).
>
> Well, I keep being screwed by when I was lazy and had previously done
> a srcdir==builddir build. spirv_info.lo failed to build, because
> .deps/spirv_info.Plo was pointing at the srcdir variant, long after it
> stopped existing; I couldn't find a better way to fix that than just
> manually hacking the .Plo file to remove the dependency. Similarly,
> marshal.c was breaking the build for me because it was picking up an
> outdated version in the srcdir (newer version in the builddir), and so
> on, and so forth.
I think you've starter perfectly - "when I was lazy.. $list of problems".
When I have issues like that I'd just git clean it, go back to the
important things.

> (Yesterday I got bitten by LLVM LDFLAGS including
> /usr/lib64 which meant that system libraries were preferred to my
> local prefix; today I got bitten by libtool relinking on install also
> refusing to find xcb-dri3 from my local prefix, which I didn't find a
> better way to fix than just copying my local lib into the system path.
> It's been a really, really, bad week for me with build systems.)
>
FWIW others (cmake, meson) also relink upon install. Back on point -
set LD_LIBRARY_PATH (see our .travis.yml) and you should be good to
go.

> Anyway, the reason I say this is because it's not just the
> -client-protocol.h header but the -protocol.c source file as well.
> Given I've been bitten by autotools being confused by files being
> present in both the srcdir and the builddir, I'm reluctant about
> adding another way this could go wrong.
>
Things can [and do] go wrong, regardless. Props to all the people
using and testing, we can address things promptly.

Tl;Dr; I'd rather stay consistent and follow with any issues when they appear.

Thanks
Emil