[Mesa-dev] [PATCH] configure.ac: Add --with-wayland-scanner-path
Modify wayland-scanner lookup: Use the path given by pkg-config but offer an option to override the path with "--with-wayland-scanner-path=PATH". The latter is useful for cross-compile situations. AC_PATH_PROG is no longer used (if the scanner is installed it should get found by pkg-config). AC_SUBST is added so the output variable is created when only the configure option is used. --- My goal is to standardize wayland-scanner usage in a way that does not require patching when cross-compiling in Yocto (the detailed issue is that in Yocto pkg-config will return a "wayland_scanner" variable but that will contain a _target path_ when we would like to use a native sysroot path instead). I've sent a similar patch to weston and intend to fix other projects if these two patches are well received. Thanks, Jussi configure.ac | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 06883a9667..89fa99e0b1 100644 --- a/configure.ac +++ b/configure.ac @@ -1661,12 +1661,19 @@ if test "x$with_platforms" = xauto; then with_platforms=$with_egl_platforms fi -PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner], + +AC_ARG_WITH([wayland-scanner-path], +[AS_HELP_STRING([--with-wayland-scanner-path=PATH], +[Path to wayland-scanner (by default the path from +'pkg-config --variable=wayland_scanner wayland-scanner' is used)])], +[WAYLAND_SCANNER="$withval"], +[WAYLAND_SCANNER="auto"]) +if test x$WAYLAND_SCANNER = xauto; then +PKG_CHECK_MODULES([WAYLAND_SCANNER], [wayland-scanner], WAYLAND_SCANNER=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`, -WAYLAND_SCANNER='') -if test "x$WAYLAND_SCANNER" = x; then -AC_PATH_PROG([WAYLAND_SCANNER], [wayland-scanner], [:]) +WAYLAND_SCANNER=":") fi +AC_SUBST(WAYLAND_SCANNER) # Do per platform setups and checks platforms=`IFS=', '; echo $with_platforms` @@ -1677,7 +1684,7 @@ for plat in $platforms; do PKG_CHECK_MODULES([WAYLAND], [wayland-client >= $WAYLAND_REQUIRED wayland-server >= $WAYLAND_REQUIRED]) if test "x$WAYLAND_SCANNER" = "x:"; then - AC_MSG_ERROR([wayland-scanner is needed to compile the wayland platform]) + AC_MSG_ERROR([wayland-scanner is needed by Wayland platform but it could not be found and --with-wayland-scanner-path was not used]) fi DEFINES="$DEFINES -DHAVE_WAYLAND_PLATFORM" ;; -- 2.11.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-wayland-scanner-path
On 23 May 2017 at 11:13, Jussi Kukkonen wrote: > > Modify wayland-scanner lookup: Use the path given by pkg-config > but offer an option to override the path with > "--with-wayland-scanner-path=PATH". The latter is useful for > cross-compile situations. > > AC_PATH_PROG is no longer used (if the scanner is installed it should > get found by pkg-config). AC_SUBST is added so the output variable is > created when only the configure option is used. > --- > > My goal is to standardize wayland-scanner usage in a way that does not > require patching when cross-compiling in Yocto (the detailed issue is > that in Yocto pkg-config will return a "wayland_scanner" variable but > that will contain a _target path_ when we would like to use a native > sysroot path instead). > > I've sent a similar patch to weston and intend to fix other projects > if these two patches are well received. wayland-devel is clearly not 100% convinced about this approach so I suggest dropping this patch as well: Feedback is still welcome. Cheers, Jussi ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-wayland-scanner-path
On 24 May 2017 at 16:39, Emil Velikov wrote:
>
> Hi Jussi,
>
> On 23 May 2017 at 09:13, Jussi Kukkonen wrote:
> > Modify wayland-scanner lookup: Use the path given by pkg-config
> > but offer an option to override the path with
> > "--with-wayland-scanner-path=PATH". The latter is useful for
> > cross-compile situations.
> >
> > AC_PATH_PROG is no longer used (if the scanner is installed it should
> > get found by pkg-config). AC_SUBST is added so the output variable is
> > created when only the configure option is used.
> > ---
> >
> > My goal is to standardize wayland-scanner usage in a way that does not
> > require patching when cross-compiling in Yocto (the detailed issue is
> > that in Yocto pkg-config will return a "wayland_scanner" variable but
> > that will contain a _target path_ when we would like to use a native
> > sysroot path instead).
> >
> > I've sent a similar patch to weston and intend to fix other projects
> > if these two patches are well received.
> >
> I might have misread something, but on a quick look the patch does not
> look quite right. Stepping aside for a moment,
>
> Can you explain clearly what's happening/wrong in the whole scenario?
> - Yocto does has A stage where it does X.
> - Then it proceeds to B... at which point $file
> foo/wayland-scanner.pc gets picked
> - That results in an error due to variable containing $bar, due to
> the $step above
Hi Emil,
I'm hoping this is a coherent enough explanation of the issue...
When yocto cross-compiles mesa for target, we already have
a) All dependency headers and libraries in a target sysroot
b) Native wayland-scanner in a native sysroot
The problem as I see it is that there is no way to express the _native_
sysroot in pkg-config: PKG_CONFIG_SYSROOT_DIR and pc_sysroot_dir logically
refer to the target sysroot. So when mesa configure does "pkg-config
--variable=wayland_scanner wayland-scanner" it gets a reasonable
"/usr/bin/wayland-scanner" response: this would be the correct path to
wayland-scanner on _target_. In the best case this fails during compile
when the scanner isn't found but unfortunately /usr/bin/wayland-scanner is
often also a valid path to _host_ wayland-scanner which might be from a
completely different and unrelated wayland version...
I could see two options to solve our problem:
* Use AC_PATH_PROG to find wayland-scanner. Weston currently does this and
it works fine for the Yocto case... but I can see how that's not perfect
either as it could find an older installed wayland-scanner in other
situations
* Use something like
"--with-wayland-scanner-path=${NATIVE_SYSROOT_BINDIR}/wayland-scanner" when
calling mesa configure: this adds a configuration item but is much, much
nicer than the current situation where we need to patch configure.ac
Thanks,
Jussi
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-wayland-scanner-path
On 26 May 2017 at 14:32, Emil Velikov wrote:
>
> On 26 May 2017 at 08:52, Jussi Kukkonen wrote:
> >
> >
> > On 24 May 2017 at 16:39, Emil Velikov wrote:
> >>
> >> Hi Jussi,
> >>
> >> On 23 May 2017 at 09:13, Jussi Kukkonen
wrote:
> >> > Modify wayland-scanner lookup: Use the path given by pkg-config
> >> > but offer an option to override the path with
> >> > "--with-wayland-scanner-path=PATH". The latter is useful for
> >> > cross-compile situations.
> >> >
> >> > AC_PATH_PROG is no longer used (if the scanner is installed it should
> >> > get found by pkg-config). AC_SUBST is added so the output variable is
> >> > created when only the configure option is used.
> >> > ---
> >> >
> >> > My goal is to standardize wayland-scanner usage in a way that does
not
> >> > require patching when cross-compiling in Yocto (the detailed issue is
> >> > that in Yocto pkg-config will return a "wayland_scanner" variable but
> >> > that will contain a _target path_ when we would like to use a native
> >> > sysroot path instead).
> >> >
> >> > I've sent a similar patch to weston and intend to fix other projects
> >> > if these two patches are well received.
> >> >
> >> I might have misread something, but on a quick look the patch does not
> >> look quite right. Stepping aside for a moment,
> >>
> >> Can you explain clearly what's happening/wrong in the whole scenario?
> >> - Yocto does has A stage where it does X.
> >> - Then it proceeds to B... at which point $file
> >> foo/wayland-scanner.pc gets picked
> >> - That results in an error due to variable containing $bar, due to
> >> the $step above
> >
> > Hi Emil,
> >
> > I'm hoping this is a coherent enough explanation of the issue...
> >
> > When yocto cross-compiles mesa for target, we already have
> > a) All dependency headers and libraries in a target sysroot
> > b) Native wayland-scanner in a native sysroot
> >
> > The problem as I see it is that there is no way to express the _native_
> > sysroot in pkg-config: PKG_CONFIG_SYSROOT_DIR and pc_sysroot_dir
logically
> > refer to the target sysroot. So when mesa configure does "pkg-config
> > --variable=wayland_scanner wayland-scanner" it gets a reasonable
> > "/usr/bin/wayland-scanner" response: this would be the correct path to
> > wayland-scanner on _target_. In the best case this fails during compile
when
> > the scanner isn't found but unfortunately /usr/bin/wayland-scanner is
often
> > also a valid path to _host_ wayland-scanner which might be from a
completely
> > different and unrelated wayland version...
> >
> Barring an important s/pkg-config/$PKG_CONFIG/ I think I agree here.
>
> AFAICT there are a couple of alternative solutions - have you
> considered/tried any of them?
>
> a) w/o a wrapper script
> $ export PKG_CONFIG_PATH= // you need this if using the system
> pkgo-config. if the local/native one is used, this should be optional
> $ export
PKG_CONFIG_LIBDIR=$path_to_non_system_host_pkgconfig:${SYSROOT}/usr/{lib,share}/pkgconfig
> $ export PKG_CONFIG_SYSROOT_DIR=${SYSROOT}
We're using a natively built pkg-config which sets all the pkg-config
variables to what I believe are the correct values: the problem is that
none of those variable is for the _native_ sysroot location so they don't
help in this case. There is now way to say in a .pc file that this path
should be prefixed with something like "${pc_native_sysroot_dir}" if it's
defined.
> b) with a wrapper script - see [1].
> I think that the "export PKG_CONFIG_DIR=" is a typo (should be ..PATH
> instead) and is not strictly required - feel free to check either way.
> Note that the exec at the end might need to be amended to
> /path/to/$(CHOST)-pkg-config.
We don't provide a target wrapper -- I believe because it provides no value
at all on top of the setup we have (the pkg-config that autotools finds has
all the environment variables set correctly. It is essentially
$(CHOST)-pkg-config already).
If I've missed something, I'd be happy to hear that. At the moment I think
pkg-config just does not help in this case.
Thanks,
Jussi
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-wayland-scanner-path
On 26 May 2017 at 17:08, Daniel Stone wrote: > Hi Jussi, > > On 26 May 2017 at 14:55, Jussi Kukkonen wrote: > > On 26 May 2017 at 14:32, Emil Velikov wrote: > >> b) with a wrapper script - see [1]. > >> I think that the "export PKG_CONFIG_DIR=" is a typo (should be ..PATH > >> instead) and is not strictly required - feel free to check either way. > >> Note that the exec at the end might need to be amended to > >> /path/to/$(CHOST)-pkg-config. > > > > We don't provide a target wrapper -- I believe because it provides no > value > > at all on top of the setup we have (the pkg-config that autotools finds > has > > all the environment variables set correctly. It is essentially > > $(CHOST)-pkg-config already). > > > > If I've missed something, I'd be happy to hear that. At the moment I > think > > pkg-config just does not help in this case. > > Thinking out loud, how about searching for a separate pkg-config file > (wayland-scanner-native.pc as a strawman) first, then falling back to > wayland-scanner.pc? The BitBake recipes could then install that > somewhere in $PKG_CONFIG_PATH as a special case in the install target. > Maybe I don't understand but that doesn't sound any easier: wayland would still need to be modified (to install an additional pc-file) and all the wayland-scanner users would need to be modified to look for that new pc file (unless you meant pkg-config would be modified to always look for "-native.pc"). I don't really mind if our case requires a configure option in every wayland-scanner using project, I'd just like to avoid patching build systems. Jussi ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-wayland-scanner-path
On 29 May 2017 at 15:20, Emil Velikov wrote:
>
> On 26 May 2017 at 14:55, Jussi Kukkonen wrote:
> > On 26 May 2017 at 14:32, Emil Velikov wrote:
> >>
> >> On 26 May 2017 at 08:52, Jussi Kukkonen
wrote:
> >> >
> >> >
> >> > On 24 May 2017 at 16:39, Emil Velikov
wrote:
> >> AFAICT there are a couple of alternative solutions - have you
> >> considered/tried any of them?
> >>
> >> a) w/o a wrapper script
> >> $ export PKG_CONFIG_PATH= // you need this if using the system
> >> pkgo-config. if the local/native one is used, this should be optional
> >> $ export
> >>
PKG_CONFIG_LIBDIR=$path_to_non_system_host_pkgconfig:${SYSROOT}/usr/{lib,share}/pkgconfig
> >> $ export PKG_CONFIG_SYSROOT_DIR=${SYSROOT}
> >
> > We're using a natively built pkg-config which sets all the pkg-config
> > variables to what I believe are the correct values: the problem is that
none
> > of those variable is for the _native_ sysroot location so they don't
help in
> > this case. There is now way to say in a .pc file that this path should
be
> > prefixed with something like "${pc_native_sysroot_dir}" if it's
defined.
> >
> >> b) with a wrapper script - see [1].
> >> I think that the "export PKG_CONFIG_DIR=" is a typo (should be ..PATH
> >> instead) and is not strictly required - feel free to check either way.
> >> Note that the exec at the end might need to be amended to
> >> /path/to/$(CHOST)-pkg-config.
> >
> > We don't provide a target wrapper -- I believe because it provides no
value
> > at all on top of the setup we have (the pkg-config that autotools finds
has
> > all the environment variables set correctly. It is essentially
> > $(CHOST)-pkg-config already).
> >
> > If I've missed something, I'd be happy to hear that. At the moment I
think
> > pkg-config just does not help in this case.
> >
> I'm confused a bit - did you try the above suggestions? If so can you
> share which one and how it fails?
I'm sorry but I do not see what I could test that could help: I mentioned
that the pkg-config that gets used by PKG_CHECK_MODULES() is essentially a
wrapped one: In more detail the build tool sets these variables:
export PKG_CONFIG_DIR = "${STAGING_DIR_HOST}${libdir}/pkgconfig"
export PKG_CONFIG_PATH = "${PKG_CONFIG_DIR}:${STAGING_DATADIR}/pkgconfig"
export PKG_CONFIG_LIBDIR = "${PKG_CONFIG_DIR}"
export PKG_CONFIG_SYSROOT_DIR = "${STAGING_DIR_HOST}"
export PKG_CONFIG_DISABLE_UNINSTALLED = "yes"
export PKG_CONFIG_SYSTEM_LIBRARY_PATH = "${base_libdir}:${libdir}"
export PKG_CONFIG_SYSTEM_INCLUDE_PATH = "${includedir}"
When we're building target software STAGING_DIR_HOST is the target sysroot.
This setup works fine for everything except the case where pkg-config is
used to locate tools that need to be run during the build (like
wayland_scanner variable): we wouldn't want to use tools from the target
sysroot.
When e.g. target mesa is being built a native sysroot already exists and it
contains a wayland-scanner we should run. but there is no way to tell
pkg-config
a) native sysroot path (via a env variable)
b) that variable wayland_scanner specifically should be prefixed with
native sysroot if present (similar to ${pc_sysrootdir} but for native
sysroot)
Jussi
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-wayland-scanner-path
On 26 May 2017 at 17:08, Daniel Stone wrote: > Hi Jussi, > > On 26 May 2017 at 14:55, Jussi Kukkonen wrote: > > On 26 May 2017 at 14:32, Emil Velikov wrote: > >> b) with a wrapper script - see [1]. > >> I think that the "export PKG_CONFIG_DIR=" is a typo (should be ..PATH > >> instead) and is not strictly required - feel free to check either way. > >> Note that the exec at the end might need to be amended to > >> /path/to/$(CHOST)-pkg-config. > > > > We don't provide a target wrapper -- I believe because it provides no > value > > at all on top of the setup we have (the pkg-config that autotools finds > has > > all the environment variables set correctly. It is essentially > > $(CHOST)-pkg-config already). > > > > If I've missed something, I'd be happy to hear that. At the moment I > think > > pkg-config just does not help in this case. > > Thinking out loud, how about searching for a separate pkg-config file > (wayland-scanner-native.pc as a strawman) first, then falling back to > wayland-scanner.pc? The BitBake recipes could then install that > somewhere in $PKG_CONFIG_PATH as a special case in the install target. > I think I just understood what you meant: That a modified "wayland-scanner-native.pc" is installed as wayland-scanner.pc but only in the sysroot case: the real target wayland-scanner.pc would not be modified. This sounds like it's worth trying, thanks. Jussi ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Add --with-wayland-scanner-path
On 29 May 2017 at 18:10, Emil Velikov wrote:
> On 29 May 2017 at 14:05, Jussi Kukkonen wrote:
> > On 29 May 2017 at 15:20, Emil Velikov wrote:
> >>
> >> On 26 May 2017 at 14:55, Jussi Kukkonen
> wrote:
> >> > On 26 May 2017 at 14:32, Emil Velikov
> wrote:
> >> >>
> >> >> On 26 May 2017 at 08:52, Jussi Kukkonen
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On 24 May 2017 at 16:39, Emil Velikov
> >> >> > wrote:
> >> >> AFAICT there are a couple of alternative solutions - have you
> >> >> considered/tried any of them?
> >> >>
> >> >> a) w/o a wrapper script
> >> >> $ export PKG_CONFIG_PATH= // you need this if using the system
> >> >> pkgo-config. if the local/native one is used, this should be optional
> >> >> $ export
> >> >>
> >> >> PKG_CONFIG_LIBDIR=$path_to_non_system_host_pkgconfig:${SYSRO
> OT}/usr/{lib,share}/pkgconfig
> >> >> $ export PKG_CONFIG_SYSROOT_DIR=${SYSROOT}
> >> >
> >> > We're using a natively built pkg-config which sets all the pkg-config
> >> > variables to what I believe are the correct values: the problem is
> that
> >> > none
> >> > of those variable is for the _native_ sysroot location so they don't
> >> > help in
> >> > this case. There is now way to say in a .pc file that this path should
> >> > be
> >> > prefixed with something like "${pc_native_sysroot_dir}" if it's
> >> > defined.
> >> >
> >> >> b) with a wrapper script - see [1].
> >> >> I think that the "export PKG_CONFIG_DIR=" is a typo (should be ..PATH
> >> >> instead) and is not strictly required - feel free to check either
> way.
> >> >> Note that the exec at the end might need to be amended to
> >> >> /path/to/$(CHOST)-pkg-config.
> >> >
> >> > We don't provide a target wrapper -- I believe because it provides no
> >> > value
> >> > at all on top of the setup we have (the pkg-config that autotools
> finds
> >> > has
> >> > all the environment variables set correctly. It is essentially
> >> > $(CHOST)-pkg-config already).
> >> >
> >> > If I've missed something, I'd be happy to hear that. At the moment I
> >> > think
> >> > pkg-config just does not help in this case.
> >> >
> >> I'm confused a bit - did you try the above suggestions? If so can you
> >> share which one and how it fails?
> >
> >
> > I'm sorry but I do not see what I could test that could help: I mentioned
> > that the pkg-config that gets used by PKG_CHECK_MODULES() is essentially
> a
> > wrapped one: In more detail the build tool sets these variables:
> >
> Giving it a try won't hurt, right ;-)
>
> But on a more serious note:
> [1] Like any project in the wild Yocto might have bugs, please try w/o it.
> [2] A simple test [w/o Yocto] with my earlier suggestion seems to work fine
>
>
You're right, definitely doesn't hurt to try (and yocto surely has bugs in
it). I'll take a step back, have another look at the whole pkg-config setup
and try some tests -- your comment about PKG_CONFIG_DIR seems completely
correct.
The example test you gave still doesn't seem to work right though, see
below.
> Thanks
> Emil
>
> [1] From a quick look Yocto seems to be doing things a bit strange, wrong
> even?
> This is the first time I'm looking through it, so I may be wrong.
>
> Some examples, with the first and foremost being the prime suspect why
> things don't work as expected.
> * Yocto uses PKG_CONFIG_DIR. The variable is not a thing used by
> pkg-config (or pkgconf).
> Yes sometimes it's used only to be fed into LIBDIR/PATH
> (meta/conf/bitbake.conf), but it does not seem consistent.
> IMHO a good first step would be is to drop or rename it to PATH.
>
> * The native pkg-config has correct PATH/LIBDIR burned into the binary
> * A pkg-config-native wrapper also sets the PATH/LIBDIR variables
> - those are the default already stored within the binary
> - SYSROOT_DIR is explicitly discarded
> * Any PKG_CHECK_MODULES(.*) calls are discarded(??) - see
> wayland_1.11.0.bb
>
> [2] The following seems to work based on a quick test.
>
> -- Layout
>
> /usr/bin/{pkg-config,wayland-scanner}
> /usr/lib/pkgconfig/wayland-scanner.pc
>
> /nativ
Re: [Mesa-dev] [PATCH mesa] configure: only install khrplatform.h if needed
On 14 July 2017 at 13:59, Eric Engestrom wrote: > khrplatform.h is only used by EGL and GLES; let's only install it when > one of those is enabled. > > Cc: mesa-sta...@lists.freedesktop.org > Signed-off-by: Eric Engestrom > This is clearly better than my patch, thanks. If it helps: Reviewed-by: Jussi Kukkonen > --- > configure.ac | 3 +++ > src/mapi/Makefile.am | 2 ++ > 2 files changed, 5 insertions(+) > > diff --git a/configure.ac b/configure.ac > index 61d98e28e0..46fcd8f3fe 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1291,6 +1291,9 @@ AM_CONDITIONAL(HAVE_OPENGL_ES2, test > "x$enable_gles2" = xyes) > AM_CONDITIONAL(NEED_OPENGL_COMMON, test "x$enable_opengl" = xyes -o \ > "x$enable_gles1" = xyes -o \ > "x$enable_gles2" = xyes) > +AM_CONDITIONAL(NEED_KHRPLATFORM, test "x$enable_egl" = xyes -o \ > + "x$enable_gles1" = xyes -o \ > + "x$enable_gles2" = xyes) > > # Validate GLX options > if test "x$enable_glx" = xyes; then > diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am > index 9ff70a14fd..83e32d2185 100644 > --- a/src/mapi/Makefile.am > +++ b/src/mapi/Makefile.am > @@ -242,5 +242,7 @@ es2api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml > $(glapi_gen_mapi_deps) > > include $(top_srcdir)/install-lib-links.mk > > +if NEED_KHRPLATFORM > khrdir = $(includedir)/KHR > khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h > +endif > -- > Cheers, > Eric > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mapi: Only install khrplatform.h with EGL or GLES
When mesa is built with "--disable-egl --disable-gles1 --disable-gles2" the KHR platform headers are not needed. Not installing the header when not needed allows using mesa for GL and another implementation for GLES+EGL (as is done in practice with userland on raspberrypi). --- src/mapi/Makefile.am | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/src/mapi/Makefile.am b/src/mapi/Makefile.am index 9ff70a14fd..94c77fb82c 100644 --- a/src/mapi/Makefile.am +++ b/src/mapi/Makefile.am @@ -188,6 +188,8 @@ es1api_libGLESv1_CM_la_LDFLAGS = \ $(LD_NO_UNDEFINED) es1api_libGLESv1_CM_la_LIBADD += shared-glapi/libglapi.la + +khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h endif es1api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml $(glapi_gen_mapi_deps) @@ -233,6 +235,12 @@ es2api_libGLESv2_la_LDFLAGS = \ $(LD_NO_UNDEFINED) es2api_libGLESv2_la_LIBADD += shared-glapi/libglapi.la + +khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h +endif + +if HAVE_EGL +khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h endif es2api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml $(glapi_gen_mapi_deps) @@ -243,4 +251,3 @@ es2api/glapi_mapi_tmp.h: glapi/gen/gl_and_es_API.xml $(glapi_gen_mapi_deps) include $(top_srcdir)/install-lib-links.mk khrdir = $(includedir)/KHR -khr_HEADERS = $(top_srcdir)/include/KHR/khrplatform.h -- 2.13.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: Check for expat when building just vulkan
Intel vulkan drivers also need expat: make sure EXPAT_LIBS is set even if dri is disabled. --- configure.ac | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 61d98e28e0..01a8b24736 100644 --- a/configure.ac +++ b/configure.ac @@ -1778,6 +1778,16 @@ if test "x$with_dri_drivers" = xno; then with_dri_drivers='' fi +# Check for expat, needed by dri and intel drivers +PKG_CHECK_MODULES([EXPAT], [expat], [have_expat=yes], +# expat version 2.0 and earlier do not provide expat.pc +[AC_CHECK_HEADER([expat.h], +[AC_CHECK_LIB([expat],[XML_ParserCreate], +[have_expat=yes + EXPAT_LIBS="-lexpat"], +[have_expat=no])], +[have_expat=no])]) + dnl If $with_dri_drivers is yes, drivers will be added through dnl platform checks. Set DEFINES and LIB_DEPS if test "x$enable_dri" = xyes; then @@ -1811,14 +1821,9 @@ if test "x$enable_dri" = xyes; then with_dri_drivers="i915 i965 nouveau r200 radeon swrast" fi -# Check for expat -PKG_CHECK_MODULES([EXPAT], [expat], [], -# expat version 2.0 and earlier do not provide expat.pc -[AC_CHECK_HEADER([expat.h],[], - [AC_MSG_ERROR([Expat headers required for DRI not found])]) - AC_CHECK_LIB([expat],[XML_ParserCreate],[], - [AC_MSG_ERROR([Expat library required for DRI not found])]) - EXPAT_LIBS="-lexpat"]) +if test "x$have_expat" = "xno"; then +AC_MSG_ERROR([Expat library required for DRI was not found]) +fi # put all the necessary libs together DRI_LIB_DEPS="$DRI_LIB_DEPS $SELINUX_LIBS $LIBDRM_LIBS $EXPAT_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS" @@ -1957,6 +1962,9 @@ if test -n "$with_vulkan_drivers"; then xintel) require_libdrm "ANV" require_x11_dri3 "ANV" +if test "x$have_expat" = "xno"; then +AC_MSG_ERROR([Expat library required for Intel Vulkan driver was not found]) +fi HAVE_INTEL_VULKAN=yes ;; xradeon) -- 2.14.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Check for expat when building just vulkan
On 28 August 2017 at 11:47, Emil Velikov wrote: > Hi Jussi, > > On 28 August 2017 at 08:07, Jussi Kukkonen > wrote: > > Intel vulkan drivers also need expat: make sure EXPAT_LIBS is set even > > if dri is disabled. > > We've got a similar patch in master 6f9298dbde63049da6f530ba4f4693 > ba78b01448 > Although in hindsight we'd want that in 17.2.x as well and maybe 17.1.x. > > Which Mesa version are you using? > Eh, I made the patch on master but apparently hadn't pulled after the holidays :/ Thanks for your fix and sorry for the noise. Yocto is currently still on 17.1.x but patching locally is not an issue (as long as I know it's fixed in master so long term we get rid of the patch). Jussi ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
