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

[Daniel Stone]

Hi,

On 21 July 2017 at 15:00, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 21 July 2017 at 14:19, Daniel Stone <daniel at fooishbar.org> wrote:
>> 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.

Fair enough, but we're also not bound to their terrible decisions. If
they want to make bad decisions, they can live with the consequences,
surely?

>> 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.

Sure. Where I was getting to with that is, having files be both in
your srcdir, and generated in your builddir, is an excellent way to
uncover a lot of frustrating problems when your build system has no
explicit tracking of which should be used.

>> (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.

Meson doesn't relink!

>> 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.

OK, in that case wayland-protocols and wayland-scanner should be
optional dependencies when building from a dist tarball. In fact,
given the above, if disting it then we should make it _impossible_ to
ever regenerate those sources when building from a dist tarball,
because autotools continually proves to us that it does not work
reliably when the files are in both srcdir and builddir.

Cheers,
Daniel