VERSION: bump to 19.0.0-rc1

android,autotools,i965: Fix location of float64_glsl.h
Android.mk and autotools disagree about where generated files should go, which wasn't a problem until we wanted to build a dist tarball. This corrects the problme by changing the output and include paths to be the same on android and autotools (meson already has the correct include path). Fixes: 7d7b30835c ("automake: Fix path to generated source")
2019-01-30 14:10:12 -08:00 · 2019-01-30 14:10:12 -08:00 · 2019-01-30 09:45:14 -08:00 · 2019-01-30 09:27:14 -08:00
6 changed files with 9 additions and 6 deletions
--- a/Makefile.am
+++ b/Makefile.am
@@ -22,6 +22,7 @@
 SUBDIRS = src

 AM_DISTCHECK_CONFIGURE_FLAGS = \
+	--enable-autotools \
 	--enable-dri \
 	--enable-dri3 \
 	--enable-egl \
--- a/2
+++ b/2
@@ -1 +1 @@
-19.0.0-devel
+19.0.0-rc1
--- a/configure.ac
+++ b/configure.ac
@@ -122,7 +122,7 @@ LLVM_REQUIRED_OPENCL=3.9.0
 LLVM_REQUIRED_R600=3.9.0
 LLVM_REQUIRED_RADEONSI=7.0.0
 LLVM_REQUIRED_RADV=7.0.0
-LLVM_REQUIRED_SWR=6.0.0
+LLVM_REQUIRED_SWR=7.0.0

 dnl Check for progs
 AC_PROG_CPP
@@ -2845,8 +2845,8 @@ if test -n "$with_gallium_drivers"; then
 fi

 # XXX: Keep in sync with LLVM_REQUIRED_SWR
-AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != x6.0.0 -a \
-                                              "x$LLVM_VERSION" != x6.0.1)
+AM_CONDITIONAL(SWR_INVALID_LLVM_VERSION, test "x$LLVM_VERSION" != x7.0.0 -a \
+                                              "x$LLVM_VERSION" != x7.0.1)

 if test "x$enable_llvm" = "xyes" -a "$with_gallium_drivers"; then
    llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
--- a/src/compiler/Android.glsl.gen.mk
+++ b/src/compiler/Android.glsl.gen.mk
@@ -104,6 +104,6 @@ $(intermediates)/glsl/ir_expression_operation_strings.h: $(LOCAL_PATH)/glsl/ir_e
 	@mkdir -p $(dir $@)
 	$(hide) $(MESA_PYTHON2) $< strings > $@

-$(intermediates)/compiler/glsl/float64_glsl.h: $(LOCAL_PATH)/glsl/xxd.py
+$(intermediates)/glsl/float64_glsl.h: $(LOCAL_PATH)/glsl/xxd.py
 	@mkdir -p $(dir $@)
 	$(hide) $(MESA_PYTHON2) $< $(MESA_TOP)/src/compiler/glsl/float64.glsl $@ -n float64_source > $@
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -34,6 +34,8 @@ AM_CFLAGS = \
 	-I$(top_builddir)/src/util \
 	-I$(top_srcdir)/src/mesa/drivers/dri/common \
 	-I$(top_srcdir)/src/gtest/include \
+	-I$(top_builddir)/src/compiler \
+	-I$(top_srcdir)/src/compiler \
 	-I$(top_builddir)/src/compiler/glsl \
 	-I$(top_builddir)/src/compiler/nir \
 	-I$(top_srcdir)/src/compiler/nir \
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -42,7 +42,7 @@
 #include "compiler/glsl/ir.h"
 #include "compiler/glsl/program.h"
 #include "compiler/glsl/glsl_to_nir.h"
-#include "compiler/glsl/float64_glsl.h"
+#include "glsl/float64_glsl.h"

 #include "brw_program.h"
 #include "brw_context.h"
Author	SHA1	Message	Date
Dylan Baker	2fddad9e3f	VERSION: bump to 19.0.0-rc1	2019-01-30 14:10:12 -08:00
Dylan Baker	2b603ee4f1	android,autotools,i965: Fix location of float64_glsl.h Android.mk and autotools disagree about where generated files should go, which wasn't a problem until we wanted to build a dist tarball. This corrects the problme by changing the output and include paths to be the same on android and autotools (meson already has the correct include path). Fixes: `7d7b30835c` ("automake: Fix path to generated source")	2019-01-30 14:10:12 -08:00
Dylan Baker	e7f6a5d17f	automake: Add --enable-autotools to distcheck flags Fixes: `e68777c87c` ("autotools: Deprecate the use of autotools")	2019-01-30 09:45:14 -08:00
Dylan Baker	1f5f12687f	configure: Bump SWR LLVM requirement to 7 It is currently impossible to build a dist tarball that works when SWR requires LLVM 6. To generate the tarball we'd need to configure with LLVM 6, which is fine. But to build the dist check we need LLVM 7, as RadeonSI and RadV require that version. Unfortunately the headers genererated with LLVM 6 don't compile with LLVM 7, the API has changed between the two versions. I weighed a couple of options here. One would be to ship an unbootstrapped tarball generated with meson. This would fix the issue by not bootstrapping, so whatever version of LLVM used would work because the SWR headers would be generated at compile time. Unfortunately this would involve some heavy modifications to the infastructure used to upload the tarballs, and I've decided not to persue this.	2019-01-30 09:27:14 -08:00