Hi Emil, On 21 July 2017 at 14:13, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 21 July 2017 at 13:28, Daniel Stone <dan...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
