On 21 July 2017 at 14:19, Daniel Stone <dan...@fooishbar.org> wrote: > 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. > 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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
