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