On 19 April 2016 at 20:47, Chad Versace <chad.vers...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev