[Mesa-dev] make distclean failing

[Emil Velikov]

On 8 October 2015 at 16:56, Rob Clark <robdclark at gmail.com> wrote:
> On Thu, Oct 8, 2015 at 11:39 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 8 October 2015 at 16:12, Matt Turner <mattst88 at gmail.com> wrote:
>>> On Thu, Oct 8, 2015 at 6:56 AM, Rob Clark <robdclark at gmail.com> wrote:
>>>> On Wed, Oct 7, 2015 at 6:00 PM, Andy Furniss <adf.lists at 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