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

[Daniel Stone]

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.

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

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.

Cheers,
Daniel