[Mesa-dev] [PATCH 01/13] i965: Add a dependency on libisl

[Emil Velikov]

On 19 April 2016 at 20:47, Chad Versace <chad.versace at intel.com> wrote:
> On Sat 16 Apr 2016, Jason Ekstrand wrote:
>> ---
>>  configure.ac                          | 3 ++-
>>  src/Makefile.am                       | 9 +++++++--
>>  src/intel/Makefile.am                 | 4 ----
>>  src/mesa/drivers/dri/i965/Makefile.am | 7 ++++++-
>>  4 files changed, 15 insertions(+), 8 deletions(-)
>
>
>> diff --git a/src/Makefile.am b/src/Makefile.am
>> index a0572b7..e9745d4 100644
>> --- a/src/Makefile.am
>> +++ b/src/Makefile.am
>> @@ -24,6 +24,10 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi
>>  # include only conditionally ?
>>  SUBDIRS += compiler
>>
>> +if HAVE_INTEL_DRIVERS
>> +SUBDIRS += intel
>> +endif
>> +
>>  if NEED_OPENGL_COMMON
>>  SUBDIRS += mesa
>>  endif
>> @@ -56,8 +60,9 @@ EXTRA_DIST = \
>>  AM_CFLAGS = $(VISIBILITY_CFLAGS)
>>  AM_CXXFLAGS = $(VISIBILITY_CXXFLAGS)
>>
>> -if HAVE_INTEL_DRIVERS
>> -SUBDIRS += intel
>> +# This explicitly comes later because it depends on the i965 compiler
>> +if HAVE_INTEL_VULKAN
>> +SUBDIRS += intel/vulkan
>>  endif
>>
>>  AM_CPPFLAGS = \
>> diff --git a/src/intel/Makefile.am b/src/intel/Makefile.am
>> index c3673c6..520602d 100644
>> --- a/src/intel/Makefile.am
>> +++ b/src/intel/Makefile.am
>> @@ -20,7 +20,3 @@
>>  # IN THE SOFTWARE.
>>
>>  SUBDIRS = genxml isl
>> -
>> -if HAVE_INTEL_VULKAN
>> -SUBDIRS += vulkan
>> -endif
>
> Moving the src/intel/vulkan from src/intel/Makefile.am to
> src/Makefile.am makes breaks a long-standing development pattern.
> Post-patch, if I do this:
>
>     $ cd $MESA_TOP/src/intel
>     $ ed vulkan/anv_cmd_buffer.c
>     $ make # SURPRISE! No vulkan code is rebuilt and your driver is weirdly out-of-date.
>
Unless you consider that nothing will ever move (be that a single file
or a whole folder) using this is strongly ill-advised.

One *might* be able to get around it by following the approach use by
xserver (configure keeps track of the static libraries used for the
final foo.so binary) although reportedly that did break something in
their dependency tracking.

> Do you see a way to fix this problem in the short-term (that is, inside
> this patch series and not *eventually*). I don't think the problem is so
> bad that it should void the patch series, but I did want to raise it to
> everyone's attention.
>
Thank you for that. Pretty sure others are abound to run (have ran)
into similar issues.

-Emil