On 8 October 2015 at 16:56, Rob Clark <robdcl...@gmail.com> wrote: > On Thu, Oct 8, 2015 at 11:39 AM, Emil Velikov <emil.l.veli...@gmail.com> > wrote: >> On 8 October 2015 at 16:12, Matt Turner <matts...@gmail.com> wrote: >>> On Thu, Oct 8, 2015 at 6:56 AM, Rob Clark <robdcl...@gmail.com> wrote: >>>> On Wed, Oct 7, 2015 at 6:00 PM, Andy Furniss <adf.li...@gmail.com> wrote: >>>>> Noticed recently that make distclean is failing for me - >>>>> >>>>> Making distclean in mesa >>>>> make[2]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/mesa' >>>>> Makefile:2486: ../glsl/.deps/shader_enums.Plo: No such file or directory >>>>> make[2]: *** No rule to make target '../glsl/.deps/shader_enums.Plo'. >>>>> Stop. >>>>> make[2]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/mesa' >>>>> Makefile:684: recipe for target 'distclean-recursive' failed >>>>> make[1]: *** [distclean-recursive] Error 1 >>>>> make[1]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src' >>>>> Makefile:615: recipe for target 'distclean-recursive' failed >>>>> make: *** [distclean-recursive] Error 1 >>>> >>>> I think the problem is that shader_enums gets cleaned twice, since it >>>> is built both into libglsl_util.la (for non-mesa state trackers, from >>>> src/Makefile.am), and into libmesa.la/libmesagallium.la (for mesa and >>>> mesa state tracker, from src/mesa/Makefile.am).. the arrangement with >>>> nir depending on some parts from glsl is a bit unfortunate. >>> >>> Ugh, yeah, that seems very plausible. The intention of adding that >>> convenience library was to avoid this very problem. :( >> Fwiw I'm inclined to move the functions as static inline, considering >> they are pretty trivial. >> It should resolve the issue, plus we'll remove ../ from the sources list. >> >> I'll send a patch in a minute > > functions are trivial but bunch of const string data that I was hoping > to avoid duplicating in many object files.. Was under the impression that the linker will kindly clean it up for us ? Let me check the numbers.
> I guess it would be an ok > temporary solution. Although maybe we should just move everything > that nir depends on into nir and have glsl depend on nir rather than > other way around.. > That would be amazing. I would gladly review any patches in that area. -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
