isa/mutter
1
0
Fork 0
mirror of https://github.com/brl/mutter.git synced 2024-11-26 18:11:05 -05:00
Code Issues Packages Projects Releases Wiki Activity
40281e608b
mutter/configure.ac

1032 lines
37 KiB
Plaintext
Raw Normal View History

Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
AC_PREREQ(2.59)
dnl ================================================================
dnl XXX: If you are making a release then you need to check these
dnl sections:
Release 1.7.0 (snapshot)
2011-06-13 06:03:04 -04:00
dnl » API versions (Only the 1.x version needs to change)
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl (the pretty numbers that the users see)
dnl
dnl » Interface version details for libtool
dnl (the shared library versioning information)
dnl
dnl » Source code release status
dnl (mark the source code as being part of a "release" or from "git")
dnl ================================================================
dnl ================================================================
dnl API versions (i.e. the pretty numbers that users see)
dnl ================================================================
m4_define([cogl_major_version], [2])
m4_define([cogl_minor_version], [0])
m4_define([cogl_micro_version], [0])
m4_define([cogl_version],
[cogl_major_version.cogl_minor_version.cogl_micro_version])
dnl Since the core Cogl library has to also maintain support for the
dnl Cogl 1.x API for Clutter then we track the 1.x version separately.
Release 1.7.0 (snapshot)
2011-06-13 06:03:04 -04:00
m4_define([cogl_1_minor_version], [7])
Post-release version bump to 1.7.7
2011-08-12 12:02:13 -04:00
m4_define([cogl_1_micro_version], [7])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
m4_define([cogl_1_version], [1.cogl_1_minor_version.cogl_1_micro_version])
dnl ================================================================
dnl Interface version details for libtool
dnl ================================================================
# Note: we don't automatically deduce the libtool version info from
# the pretty version number that users sees. This is because we want
# to update the pretty version number before making a release since it
# can affect the name of our pkg-config file and the naming or
# location of other installed files which we want to be able to verify
# as correct well before making a release.
#
# For reference on how the various numbers should be updated at
# release time these rules are adapted from the libtool info pages:
#
# 1. Update the version information only immediately before a public
# release.
#
# 2. If the library source code has changed at all since the last
# update, then increment REVISION (`C:R:A' becomes `C:r+1:A').
#
# 3. If any interfaces have been added, removed, or changed since the
# last update, increment CURRENT, and set REVISION to 0.
#
# 4. If any interfaces have been added since the last public release,
# then increment AGE.
#
# 5. If any interfaces have been removed since the last public release,
# then set AGE to 0.
Release 1.7.6 (snapshot)
2011-08-12 12:00:41 -04:00
m4_define([cogl_lt_current], 3)
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
m4_define([cogl_lt_revision], 0)
Release 1.7.6 (snapshot)
2011-08-12 12:00:41 -04:00
m4_define([cogl_lt_age], 1)
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
# We do also tell libtool the pretty version:
m4_define([cogl_lt_release], [cogl_version])
dnl ================================================================
dnl Source code release status
dnl ================================================================
# Finally we explicitly track when we are building development source
# from Git vs building source corresponding to a release. As with the
# libtool version info we don't automatically derive this from the
# pretty version number because we want to test the results of
# updating the version number in advance of a release.
Post-release version bump to 1.7.7
2011-08-12 12:02:13 -04:00
m4_define([cogl_release_status], [git])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
README: Fix the required version number replacements The README file is generated by the configure script so that it can include the required dependency version numbers. However there was no corresponding AC_SUBST calls for the versions so the README would be left with @THESE_MARKERS@.
2011-07-01 11:20:32 -04:00
AC_INIT(cogl, [cogl_1_version])
AC_CONFIG_SRCDIR(cogl/cogl.h)
AC_CONFIG_AUX_DIR([build])
AC_CONFIG_MACRO_DIR([build/autotools])
AC_CONFIG_HEADERS(config.h)
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ================================================================
dnl Required versions for dependencies
dnl ================================================================
m4_define([glib_req_version], [2.26.0])
m4_define([pangocairo_req_version], [1.20])
m4_define([gi_req_version], [0.9.5])
m4_define([gdk_pixbuf_req_version], [2.0])
m4_define([uprof_req_version], [0.3])
m4_define([gtk_doc_req_version], [1.13])
m4_define([xfixes_req_version], [3])
m4_define([xcomposite_req_version], [0.4])
README: Fix the required version number replacements The README file is generated by the configure script so that it can include the required dependency version numbers. However there was no corresponding AC_SUBST calls for the versions so the README would be left with @THESE_MARKERS@.
2011-07-01 11:20:32 -04:00
m4_define([cairo_req_version], [1.10])
dnl These variables get copied into the generated README
AC_SUBST([GLIB_REQ_VERSION], [glib_req_version])
AC_SUBST([GDK_PIXBUF_REQ_VERSION], [gdk_pixbuf_req_version])
AC_SUBST([CAIRO_REQ_VERSION], [cairo_req_version])
AC_SUBST([PANGOCAIRO_REQ_VERSION], [pangocairo_req_version])
AC_SUBST([XCOMPOSITE_REQ_VERSION], [xcomposite_req_version])
AC_SUBST([XFIXES_REQ_VERSION], [xfixes_req_version])
AC_SUBST([GTK_DOC_REQ_VERSION], [gtk_doc_req_version])
AC_SUBST([GI_REQ_VERSION], [gi_req_version])
AC_SUBST([UPROF_REQ_VERSION], [uprof_req_version])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
# Save this value here, since automake will set cflags later and we
# want to know if the user specified custom cflags or not.
cflags_set=${CFLAGS+set}
AM_INIT_AUTOMAKE([1.11 foreign -Wno-portability no-define no-dist-gzip
configure: pass tar-ustar as automake init option So that our released tarballs can contain filenames longer than 99 characters we tell automake to create tarballs using the ustar format. This is newer than the default v7 format but still old enough to be considered widely portable.
2011-06-14 10:08:17 -04:00
dist-bzip2 tar-ustar])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
AM_SILENT_RULES([yes])
configure: Force #undef of 'near' and 'far' on Windows This adds an extra header that gets included from config.h where we can add configuration defines. This is used to #undef 'near' and 'far' when building for Windows so that we don't have to avoid using them as variable names in the Cogl code.
2011-06-13 08:09:47 -04:00
AH_BOTTOM([#include "config-custom.h"])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ================================================================
dnl Export the API versioning
dnl ================================================================
AC_SUBST([COGL_MAJOR_VERSION],[cogl_major_version])
AC_SUBST([COGL_MINOR_VERSION],[cogl_minor_version])
AC_SUBST([COGL_MICRO_VERSION],[cogl_micro_version])
AC_SUBST([COGL_VERSION],[cogl_version])
AC_SUBST([COGL_API_VERSION],[cogl_major_version.0])
AC_SUBST([COGL_API_VERSION_AM],[$COGL_MAJOR_VERSION\_0])
AC_SUBST([COGL_1_MINOR_VERSION],[cogl_1_minor_version])
AC_SUBST([COGL_1_MICRO_VERSION],[cogl_1_micro_version])
AC_SUBST([COGL_1_VERSION],[cogl_1_version])
dnl ================================================================
dnl Export the libtool versioning
dnl ================================================================
AC_SUBST([COGL_LT_CURRENT], [cogl_lt_current])
AC_SUBST([COGL_LT_REVISION], [cogl_lt_revision])
AC_SUBST([COGL_LT_AGE], [cogl_lt_age])
AC_SUBST([COGL_LT_RELEASE], [cogl_lt_release])
dnl ================================================================
dnl Export the source code release status
dnl ================================================================
AC_SUBST([COGL_RELEASE_STATUS], [cogl_release_status])
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
dnl ================================================================
dnl See what platform we are building for
dnl ================================================================
AC_CANONICAL_HOST
AC_MSG_CHECKING([if building for some Win32 platform])
AS_CASE([$host],
[*-*-mingw*|*-*-cygwin*],
[
COGL_EXTRA_LDFLAGS="$COGL_EXTRA_LDFLAGS -no-undefined"
platform_win32=yes
],
[platform_win32=no]
)
AC_MSG_RESULT([$platform_win32])
AM_CONDITIONAL(OS_WIN32, [test "$platform_win32" = "yes"])
build: Fix platform detection for Quartz/OSX The location of the header files for GL and the linker flags are different on Mac OS X than other Unices.
2011-05-24 17:29:42 -04:00
AC_CHECK_HEADER([OpenGL/gl.h], [platform_quartz=yes], [platform_quartz=no])
AM_CONDITIONAL(OS_QUARTZ, [test "$platform_quartz" = "yes"])
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ================================================================
dnl Handle extra configure options
dnl ================================================================
dnl ============================================================
dnl Enable debugging
dnl ============================================================
build: Do not define "default" in m4 The "default" m4 conflicts with one of libtool's internal symbols, one that is used to determine whether the -fPIC argument should be used; this breaks compilation onf 64bit platforms. https://bugzilla.gnome.org/show_bug.cgi?id=653615 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com> Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-29 05:12:47 -04:00
m4_define([debug_default], [m4_if(cogl_release_status, [git], [yes], [no])])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
AC_ARG_ENABLE(
[debug],
build: Do not define "default" in m4 The "default" m4 conflicts with one of libtool's internal symbols, one that is used to determine whether the -fPIC argument should be used; this breaks compilation onf 64bit platforms. https://bugzilla.gnome.org/show_bug.cgi?id=653615 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com> Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-29 05:12:47 -04:00
[AC_HELP_STRING([--enable-debug=@<:@no/yes@:>@], [Control Cogl debugging level @<:@default=]debug_default[@:>@])],
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
[],
build: Do not define "default" in m4 The "default" m4 conflicts with one of libtool's internal symbols, one that is used to determine whether the -fPIC argument should be used; this breaks compilation onf 64bit platforms. https://bugzilla.gnome.org/show_bug.cgi?id=653615 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com> Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-29 05:12:47 -04:00
enable_debug=debug_default
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
)
AS_CASE(
[$enable_debug],
[yes],
[
test "$cflags_set" = set || CFLAGS="$CFLAGS -g -O0"
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
COGL_EXTRA_CFLAGS="$COGL_EXTRA_CFLAGS -DCOGL_GL_DEBUG -DCOGL_OBJECT_DEBUG -DCOGL_HANDLE_DEBUG -DCOGL_ENABLE_DEBUG"
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
],
[no],
[
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
COGL_EXTRA_CFLAGS="$COGL_EXTRA_CFLAGS -DCOGL_ENABLE_DEBUG -DG_DISABLE_CHECKS -DG_DISABLE_CAST_CHECKS"
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
],
[AC_MSG_ERROR([Unknown argument for --enable-debug])]
)
AC_SUBST(COGL_DEBUG_CFLAGS)
configure.ac: move the --enable-cairo check This moves the --enable-cairo check because it was put in the middle of the logic that handles the --enable-debug option. This moves the --enable-cairo check down after the --enable-debug logic and adds a comment header to delimit the option like we have for other options.
2011-05-27 08:59:29 -04:00
dnl ============================================================
dnl Enable cairo usage for debugging
dnl (debugging code can use cairo to dump the atlas)
dnl ============================================================
README: Fix the required version number replacements The README file is generated by the configure script so that it can include the required dependency version numbers. However there was no corresponding AC_SUBST calls for the versions so the README would be left with @THESE_MARKERS@.
2011-07-01 11:20:32 -04:00
PKG_CHECK_EXISTS([CAIRO], [cairo >= cairo_req_version], [have_cairo=yes])
configure.ac: move the --enable-cairo check This moves the --enable-cairo check because it was put in the middle of the logic that handles the --enable-debug option. This moves the --enable-cairo check down after the --enable-debug logic and adds a comment header to delimit the option like we have for other options.
2011-05-27 08:59:29 -04:00
AC_ARG_ENABLE(
[cairo],
[AC_HELP_STRING([--enable-cairo=@<:@no/yes@:>@], [Control Cairo usage in Cogl debugging code @<:@default=auto@:>@])],
[],
[
AS_IF([test "x$enable_debug" = "xyes"],
[enable_cairo=$have_cairo],
[enable_cairo=no])
]
)
AS_IF([test "x$enable_cairo" = "xyes" && test "x$enable_debug" = "xyes"],
[
AS_IF([test "x$have_cairo" != "xyes"],
[AC_MSG_ERROR([Could not find Cairo])])
README: Fix the required version number replacements The README file is generated by the configure script so that it can include the required dependency version numbers. However there was no corresponding AC_SUBST calls for the versions so the README would be left with @THESE_MARKERS@.
2011-07-01 11:20:32 -04:00
COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES cairo >= cairo_req_version"
configure.ac: move the --enable-cairo check This moves the --enable-cairo check because it was put in the middle of the logic that handles the --enable-debug option. This moves the --enable-cairo check down after the --enable-debug logic and adds a comment header to delimit the option like we have for other options.
2011-05-27 08:59:29 -04:00
AC_DEFINE([HAVE_CAIRO], [1], [Whether we have cairo or not])
])
profile: Adds a --enable-profile option This adds a --enable-profile option which enables uprof based profiling. It was also necessary to fixup a CLUTTER_ENABLE_PROFILING #ifdef in cogl-context.c to renamed COGL_ENABLE_PROFILING instead. By default Cogl doesn't output uprof reports directly, instead it assumes a higher level toolkit will output a report. If you want a report from Cogl you can export COGL_PROFILE_OUTPUT_REPORT=1 before running your app. The latest version of uprof can be fetched from: git://github.com/rib/UProf.git
2011-06-13 05:30:49 -04:00
dnl ============================================================
dnl Enable profiling
dnl ============================================================
AC_ARG_ENABLE(profile,
build: Fix the help string for --enable-profile --enable-uprof has been renamed to --enable-profile, make sure the help string is updated accordingly. Signed-off-by: Robert Bragg <robert@linux.intel.com>
2011-07-10 20:13:09 -04:00
[AC_HELP_STRING([--enable-profile=@<:@no/yes@:>@],
build: Correctly quote the help message for --enable-profile It did not show up in ./configure --help because of that. Signed-off-by: Robert Bragg <robert@linux.intel.com>
2011-07-10 20:11:22 -04:00
[Turn on uprof profiling support. yes; All UProf profiling probe points are compiled in and may be runtime enabled. no; No profiling support will built into cogl. @<:@default=no@:>@])],
profile: Adds a --enable-profile option This adds a --enable-profile option which enables uprof based profiling. It was also necessary to fixup a CLUTTER_ENABLE_PROFILING #ifdef in cogl-context.c to renamed COGL_ENABLE_PROFILING instead. By default Cogl doesn't output uprof reports directly, instead it assumes a higher level toolkit will output a report. If you want a report from Cogl you can export COGL_PROFILE_OUTPUT_REPORT=1 before running your app. The latest version of uprof can be fetched from: git://github.com/rib/UProf.git
2011-06-13 05:30:49 -04:00
[],
[enable_profile=no])
AS_IF([test "x$enable_profile" = "xyes"],
[
AS_IF([test "x$GCC" = "xyes"],
[
COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES uprof-0.3"
COGL_EXTRA_CFLAGS="$COGL_EXTRA_CFLAGS -DCOGL_ENABLE_PROFILE"
AS_IF([test "x$enable_debug" = "xyes"], [COGL_EXTRA_CFLAGS="$COGL_EXTRA_CFLAGS -DUPROF_DEBUG"])
],
[
AC_MSG_ERROR([--enable-profile is currently only supported if using GCC])
])
])
AM_CONDITIONAL(PROFILE, test "x$enable_profile" != "xno")
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ============================================================
dnl Enable strict compiler flags
dnl ============================================================
# use strict compiler flags only when building from git; the rules for
# distcheck will take care of turning this on when making a release
build: Do not define "default" in m4 The "default" m4 conflicts with one of libtool's internal symbols, one that is used to determine whether the -fPIC argument should be used; this breaks compilation onf 64bit platforms. https://bugzilla.gnome.org/show_bug.cgi?id=653615 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com> Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-29 05:12:47 -04:00
m4_define([maintainer_default], [m4_if(cogl_release_status, [git], [yes], [no])])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
AC_ARG_ENABLE(
[maintainer-flags],
build: Do not define "default" in m4 The "default" m4 conflicts with one of libtool's internal symbols, one that is used to determine whether the -fPIC argument should be used; this breaks compilation onf 64bit platforms. https://bugzilla.gnome.org/show_bug.cgi?id=653615 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com> Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-29 05:12:47 -04:00
[AC_HELP_STRING([--enable-maintainer-flags=@<:@no/yes/error@:>@], [Use strict compiler flags @<:@default=]maintainer_default[@:>@])],
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
[],
build: Do not define "default" in m4 The "default" m4 conflicts with one of libtool's internal symbols, one that is used to determine whether the -fPIC argument should be used; this breaks compilation onf 64bit platforms. https://bugzilla.gnome.org/show_bug.cgi?id=653615 Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com> Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-06-29 05:12:47 -04:00
enable_maintainer_flags=maintainer_default
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
)
don't add -Wshadow to MAINTAINER_CFLAGS The semantics of shadowing global variables is well defined and it gets quite annoying to avoid them completely since there are too many standard APIs with very poor namespacing.
2011-05-11 11:51:10 -04:00
MAINTAINER_COMPILER_FLAGS="-Wall -Wcast-align -Wuninitialized
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
-Wno-strict-aliasing -Wempty-body -Wformat
-Wformat-security -Winit-self
-Wdeclaration-after-statement -Wvla
-Wpointer-arith"
AS_CASE(
[$enable_maintainer_flags],
[yes],
[
AS_COMPILER_FLAGS([MAINTAINER_CFLAGS], [$MAINTAINER_COMPILER_FLAGS])
],
[no],
[
],
[error],
[
MAINTAINER_COMPILER_FLAGS="$MAINTAINER_COMPILER_FLAGS -Werror"
AS_COMPILER_FLAGS([MAINTAINER_CFLAGS], [$MAINTAINER_COMPILER_FLAGS])
],
[*],
[AC_MSG_ERROR([Invalid option for --enable-maintainer-flags])]
)
# strip leading spaces
build: Don't use bash string substitution in configure.ac Use the shell-neutral version. https://bugzilla.gnome.org/show_bug.cgi?id=651256
2011-06-01 11:44:57 -04:00
COGL_EXTRA_CFLAGS="$COGL_EXTRA_CFLAGS ${MAINTAINER_CFLAGS#* }"
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ============================================================
dnl Choose image loading backend
dnl ============================================================
AC_ARG_ENABLE(
[gdk-pixbuf],
[AC_HELP_STRING([--enable-gdk-pixbuf=@<:@no/yes@:>@], [Enable image loading via gdk-pixbuf @<:@default=yes@:>@])],
[],
enable_gdk_pixbuf=yes
)
if test "x$enable_gdk_pixbuf" = "xyes"; then
cogl/configure.ac: fix pkg-config checks This fixes the gdk-pixbuf check to not mistakenly check for the "xi" package instead of gdk-pixbuf and remove a spurious listing "gl" in COGL_PKG_REQUIRES which should only be there when we are using using opengl not if we are using gles.
2011-04-19 12:42:48 -04:00
PKG_CHECK_EXISTS([gdk-pixbuf-2.0], [have_gdk_pixbuf=yes], [have_gdk_pixbuf=no])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
else
have_gdk_pixbuf=no
fi
AC_ARG_ENABLE(
[quartz-image],
[AC_HELP_STRING([--enable-quartz-image=@<:@no/yes@:>@], [Enable image loading via quartz @<:@default=no@:>@])],
[],
enable_quartz_image=no
)
AS_IF(
[test "x$have_gdk_pixbuf" = "xyes"],
[
AC_DEFINE([USE_GDKPIXBUF], 1, [Use GdkPixbuf for loading image data])
COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES gdk-pixbuf-2.0 >= gdk_pixbuf_req_version"
COGL_IMAGE_BACKEND="gdk-pixbuf"
],
[test "x$enable_quartz_image" = "xyes"],
[
EXPERIMENTAL_CONFIG=yes
EXPERIMENTAL_OPTIONS="$EXPERIMENTAL_OPTIONS Quartz Core Graphics,"
AC_DEFINE([USE_QUARTZ], 1,
[Use Core Graphics (Quartz) for loading image data])
COGL_IMAGE_BACKEND="quartz"
],
[
EXPERIMENTAL_CONFIG=yes
EXPERIMENTAL_OPTIONS="$EXPERIMENTAL_OPTIONS fallback image decoding (stb_image),"
AC_DEFINE([USE_INTERNAL], 1,
[Use internal image decoding for loading image data])
COGL_IMAGE_BACKEND="stb_image"
]
)
Make building cogl-pango optional When building for platforms that don't use pango for handling text you may not need the cogl-pango library.
2011-05-05 16:39:40 -04:00
dnl ============================================================
dnl Should cogl-pango be built?
dnl ============================================================
AC_ARG_ENABLE(
[cogl-pango],
[AC_HELP_STRING([--enable-cogl-pango=@<:@no/yes@:>@], [Enable pango support @<:@default=yes@:>@])],
[],
enable_cogl_pango=yes
)
AM_CONDITIONAL([BUILD_COGL_PANGO], [test "x$enable_cogl_pango" = "xyes"])
AS_IF([test "x$enable_cogl_pango" = "xyes"],
[
build: only have libcogl-pango depend on pango Only cogl-pango needs a dependency on pangocairo so we are now careful to separate the pangocairo pkg-config flags from the others so we can avoid having libcogl builds refer to them. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-02 09:14:06 -04:00
COGL_PANGO_PKG_REQUIRES="$COGL_PANGO_PKG_REQUIRES pangocairo >= pangocairo_req_version"
Make building cogl-pango optional When building for platforms that don't use pango for handling text you may not need the cogl-pango library.
2011-05-05 16:39:40 -04:00
]
)
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ============================================================
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
dnl Determine which drivers and window systems we can support
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ============================================================
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
dnl ========================================================
dnl Drivers first...
dnl ========================================================
EGL_CHECKED=no
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
dnl This gets set to yes if Cogl directly links to the GL library API
dnl so it doesn't need to be dlopened. This currently happens on OSX
dnl and WGL where it's not clear if window system API can be separated
dnl from the GL API.
GL_LIBRARY_DIRECTLY_LINKED=no
enabled_drivers=""
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
AC_ARG_ENABLE(
[gles1],
[AC_HELP_STRING([--enable-gles1=@<:@no/yes@:>@], [Enable support for OpenGL-ES 1.1 @<:@default=no@:>@])],
[],
enable_gles1=no
)
AS_IF([test "x$enable_gles1" = "xyes"],
[
build: Fix the Win32 platform test for GLES1 We want to bail out if trying to configure Cogl with GLES1 on Windows. Not the opposite.
2011-05-12 09:26:54 -04:00
AS_IF([test "x$platform_win32" = "xyes"],
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
[AC_MSG_ERROR([GLES 1 not available for win32])])
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
enabled_drivers="$enabled_drivers gles1"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
cogl_gl_headers="GLES/gl.h GLES/glext.h"
AC_DEFINE([HAVE_COGL_GLES], 1, [Have GLES 1.1 for rendering])
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_GLES CLUTTER_COGL_HAS_GLES"
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_GLES1"
PKG_CHECK_EXISTS([glesv1_cm],
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
[COGL_PKG_REQUIRES_GL="$COGL_PKG_REQUIRES_GL glesv1_cm"
Specify the full filename when g_module_open'ing the GL library Instead of using g_module_build_path with the short name of the GL library (eg, "GL") and relying on glib to add the suffix and prefix, the configure script now directly encodes the full name including the version number (eg, "libGL.so.1"). This is necessary because distros don't always install the non-versioned suffix for the library. The GLES libraries are left without the version suffix because it's not clear what should be placed here and I can't find any documentation from Khronos to clarify this. Mesa seems to install a file called libGLESv2.so.2 but the IMG SDK doesn't install any versioned library. There is an example of dynamically loading libGLESv2 in the Chromium source code and that does not use the version suffix even though it does use the version suffix for GL. This implies that it's at least fairly normal to load the unversioned name for GLES. https://bugzilla.gnome.org/show_bug.cgi?id=654593
2011-07-18 13:07:06 -04:00
COGL_GLES1_LIBNAME="libGLESv1_CM.so"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
NEED_EGL=yes
],
[
build: Fix the GLES headers check GLES/glext.h and GLES2/gl2ext.h need to include GLES/gl.h and GLES2/gl2.h respectively to get the GL types. This used to work as autoconf used to only do a preprocessor pass in AC_CHECK_HEADER(S), but now it also tries to compile a small test program and thus the test failed.
2011-05-12 09:59:44 -04:00
# We have to check the two headers independently as GLES/glext.h
# needs to include GLES/gl.h to have the GL types defined (eg.
# GLenum).
AC_CHECK_HEADER([GLES/gl.h],
[],
[AC_MSG_ERROR([Unable to locate GLES/gl.h])])
AC_CHECK_HEADER([GLES/glext.h],
[],
[AC_MSG_ERROR([Unable to locate GLES/glext.h])],
[#include <GLES/gl.h>])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
gles1: Include GLES/egl.h or EGL/egl.h depending on the implementation Early implementations provided only a GLES/egl.h while Khronos's implementer guide now states EGL/egl.h is the One. Some implementations keep a GLES/egl.h wrapper around EGL/egl.h for backward compatibility while others provide EGL/egl.h only. Also took the opportunity to factorize a bit this inclusion in cogl-defines.h.
2011-05-13 03:04:47 -04:00
# Early implementations provided only a GLES/egl.h while Khronos's
# implementer guide now states EGL/egl.h is the One. Some
# implementations keep a GLES/egl.h wrapper around EGL/egl.h for
# backward compatibility while others provide EGL/egl.h only.
AC_CHECK_HEADERS([GLES/egl.h EGL/egl.h])
AS_IF([test "x$ac_cv_header_GLES_egl_h" = "xyes"],
egl: check or EGL/eglext.h While running configure we now check for EGL/eglext.h and if found we will substitute an inclusion in cogl-defines.h.
2011-05-24 16:33:22 -04:00
[COGL_EGL_INCLUDES="#include <GLES/egl.h>"],
[test "x$ac_cv_header_EGL_egl_h" = "xyes"],
[
COGL_EGL_INCLUDES="#include <EGL/egl.h>"
],
[AC_MSG_ERROR([Unable to locate EGL header])])
AC_SUBST([COGL_EGL_INCLUDES])
gles1: Include GLES/egl.h or EGL/egl.h depending on the implementation Early implementations provided only a GLES/egl.h while Khronos's implementer guide now states EGL/egl.h is the One. Some implementations keep a GLES/egl.h wrapper around EGL/egl.h for backward compatibility while others provide EGL/egl.h only. Also took the opportunity to factorize a bit this inclusion in cogl-defines.h.
2011-05-13 03:04:47 -04:00
egl: Make sure to have egl.h included when testing for eglext.h AC_CHECK_HEADER(S) for eglext.h need include egl.h as it may not be done for you. The patch tries to integrate with the previous work to check if GLES/egl.h ir EGL/egl.h should be included for egl.h.
2011-07-22 10:13:44 -04:00
AC_CHECK_HEADERS([EGL/eglext.h],
[COGL_EGL_INCLUDES="$COGL_EGL_INCLUDE
#include <EGL/eglext.h>"],
[],
[$COGL_EGL_INCLUDES])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
# Check for a GLES 1.x Common Profile library with/without EGL.
#
# Note: historically GLES 1 libraries shipped with the
# EGL and GLES symbols all bundled in one library. Now
# the Khronos Implementers Guide defines two naming
# schemes: -lGLES_CM should be used for a library that
# bundles the GLES and EGL API together and -lGLESv1_CM
# would be used for a standalone GLES API.
AC_CHECK_LIB(GLES_CM, [eglInitialize],
Specify the full filename when g_module_open'ing the GL library Instead of using g_module_build_path with the short name of the GL library (eg, "GL") and relying on glib to add the suffix and prefix, the configure script now directly encodes the full name including the version number (eg, "libGL.so.1"). This is necessary because distros don't always install the non-versioned suffix for the library. The GLES libraries are left without the version suffix because it's not clear what should be placed here and I can't find any documentation from Khronos to clarify this. Mesa seems to install a file called libGLESv2.so.2 but the IMG SDK doesn't install any versioned library. There is an example of dynamically loading libGLESv2 in the Chromium source code and that does not use the version suffix even though it does use the version suffix for GL. This implies that it's at least fairly normal to load the unversioned name for GLES. https://bugzilla.gnome.org/show_bug.cgi?id=654593
2011-07-18 13:07:06 -04:00
[COGL_GLES1_LIBNAME="libGLES_CM.so"],
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
[
AC_CHECK_LIB(GLESv1_CM, [glFlush],
Specify the full filename when g_module_open'ing the GL library Instead of using g_module_build_path with the short name of the GL library (eg, "GL") and relying on glib to add the suffix and prefix, the configure script now directly encodes the full name including the version number (eg, "libGL.so.1"). This is necessary because distros don't always install the non-versioned suffix for the library. The GLES libraries are left without the version suffix because it's not clear what should be placed here and I can't find any documentation from Khronos to clarify this. Mesa seems to install a file called libGLESv2.so.2 but the IMG SDK doesn't install any versioned library. There is an example of dynamically loading libGLESv2 in the Chromium source code and that does not use the version suffix even though it does use the version suffix for GL. This implies that it's at least fairly normal to load the unversioned name for GLES. https://bugzilla.gnome.org/show_bug.cgi?id=654593
2011-07-18 13:07:06 -04:00
[COGL_GLES1_LIBNAME="libGLESv1_CM.so"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
NEED_SEPARATE_EGL=yes
],
[AC_MSG_ERROR([Unable to locate required GLES 1.x Common Profile library])])
])
EGL_CHECKED=yes
])
])
AC_ARG_ENABLE(
[gles2],
[AC_HELP_STRING([--enable-gles2=@<:@no/yes@:>@], [Enable support for OpenGL-ES 2.0 @<:@default=no@:>@])],
[],
enable_gles2=no
)
AS_IF([test "x$enable_gles2" = "xyes"],
[
build: Fix the Win32 platform test for GLES2 The error message has a small typo (copy and paste from the GLES1 detection code) and the check was reversed.
2011-05-12 11:00:35 -04:00
AS_IF([test "x$platform_win32" = "xyes"],
[AC_MSG_ERROR([GLES 2 not available for win32])])
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
enabled_drivers="$enabled_drivers gles2"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
cogl_gl_headers="GLES2/gl2.h GLES2/gl2ext.h"
AC_DEFINE([HAVE_COGL_GLES2], 1, [Have GLES 2.0 for rendering])
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_GLES CLUTTER_COGL_HAS_GLES"
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_GLES2"
PKG_CHECK_EXISTS([glesv2],
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
[COGL_PKG_REQUIRES_GL="$COGL_PKG_REQUIRES_GL glesv2"
Specify the full filename when g_module_open'ing the GL library Instead of using g_module_build_path with the short name of the GL library (eg, "GL") and relying on glib to add the suffix and prefix, the configure script now directly encodes the full name including the version number (eg, "libGL.so.1"). This is necessary because distros don't always install the non-versioned suffix for the library. The GLES libraries are left without the version suffix because it's not clear what should be placed here and I can't find any documentation from Khronos to clarify this. Mesa seems to install a file called libGLESv2.so.2 but the IMG SDK doesn't install any versioned library. There is an example of dynamically loading libGLESv2 in the Chromium source code and that does not use the version suffix even though it does use the version suffix for GL. This implies that it's at least fairly normal to load the unversioned name for GLES. https://bugzilla.gnome.org/show_bug.cgi?id=654593
2011-07-18 13:07:06 -04:00
COGL_GLES2_LIBNAME="libGLESv2.so"
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
],
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
[
build: Fix the GLES headers check GLES/glext.h and GLES2/gl2ext.h need to include GLES/gl.h and GLES2/gl2.h respectively to get the GL types. This used to work as autoconf used to only do a preprocessor pass in AC_CHECK_HEADER(S), but now it also tries to compile a small test program and thus the test failed.
2011-05-12 09:59:44 -04:00
# We have to check the two headers independently as GLES2/gl2ext.h
# needs to include GLES2/gl2.h to have the GL types defined (eg.
# GLenum).
AC_CHECK_HEADER([GLES2/gl2.h],
[],
[AC_MSG_ERROR([Unable to locate GLES2/gl2.h])])
AC_CHECK_HEADER([GLES2/gl2ext.h],
[],
[AC_MSG_ERROR([Unable to locate GLES2/gl2ext.h])],
[#include <GLES2/gl2.h>])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
Specify the full filename when g_module_open'ing the GL library Instead of using g_module_build_path with the short name of the GL library (eg, "GL") and relying on glib to add the suffix and prefix, the configure script now directly encodes the full name including the version number (eg, "libGL.so.1"). This is necessary because distros don't always install the non-versioned suffix for the library. The GLES libraries are left without the version suffix because it's not clear what should be placed here and I can't find any documentation from Khronos to clarify this. Mesa seems to install a file called libGLESv2.so.2 but the IMG SDK doesn't install any versioned library. There is an example of dynamically loading libGLESv2 in the Chromium source code and that does not use the version suffix even though it does use the version suffix for GL. This implies that it's at least fairly normal to load the unversioned name for GLES. https://bugzilla.gnome.org/show_bug.cgi?id=654593
2011-07-18 13:07:06 -04:00
COGL_GLES2_LIBNAME="libGLESv2.so"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
])
NEED_EGL=yes
])
AC_ARG_ENABLE(
[gl],
[AC_HELP_STRING([--enable-gl=@<:@no/yes@:>@], [Enable support for OpenGL @<:@default=yes@:>@])],
[],
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
[enable_gl=yes]
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
)
AS_IF([test "x$enable_gl" = "xyes"],
[
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
enabled_drivers="$enabled_drivers gl"
build: Only allow GLX when finding the x11 pc file You can refine earlier the ALLOW_GLX variable when enabling OpenGL builds: No x11.pc? no GLX!
2011-05-12 06:43:27 -04:00
PKG_CHECK_EXISTS([x11], [ALLOW_GLX=yes])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
cogl_gl_headers="GL/gl.h"
build: Fix platform detection for Quartz/OSX The location of the header files for GL and the linker flags are different on Mac OS X than other Unices.
2011-05-24 17:29:42 -04:00
AS_IF([test "x$platform_quartz" = "xyes"],
[
cogl_gl_headers="OpenGL/gl.h"
COGL_EXTRA_LDFLAGS="$COGL_EXTRA_LDFLAGS -framework OpenGL"
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
dnl The GL API is being directly linked in so there is
dnl no need to dlopen it separately
GL_LIBRARY_DIRECTLY_LINKED=yes
COGL_GL_LIBNAME=""
build: Fix platform detection for Quartz/OSX The location of the header files for GL and the linker flags are different on Mac OS X than other Unices.
2011-05-24 17:29:42 -04:00
],
[test "x$platform_win32" = "xyes"],
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
[
COGL_EXTRA_LDFLAGS="$COGL_EXTRA_LDFLAGS -lopengl32 -lgdi32 -lwinmm"
COGL_EXTRA_CFLAGS="$COGL_EXTRA_CFLAGS -D_WIN32_WINNT=0x0500"
Add a WGL winsys This adds a full winsys to handle WGL and Win32.
2011-05-09 12:48:50 -04:00
ALLOW_WGL=yes
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
dnl The GL API is being directly linked in so there is
dnl no need to dlopen it separately
GL_LIBRARY_DIRECTLY_LINKED=yes
COGL_GL_LIBNAME=""
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
],
build: Fix platform detection for Quartz/OSX The location of the header files for GL and the linker flags are different on Mac OS X than other Unices.
2011-05-24 17:29:42 -04:00
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
[
build: Fix platform detection for Quartz/OSX The location of the header files for GL and the linker flags are different on Mac OS X than other Unices.
2011-05-24 17:29:42 -04:00
PKG_CHECK_EXISTS([gl],
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
dnl We don't want to use COGL_PKG_REQUIRES here because we don't want to
dnl directly link against libGL
[COGL_PKG_REQUIRES_GL="$COGL_PKG_REQUIRES_GL gl"],
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
[AC_CHECK_LIB(GL, [glGetString],
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
,
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
[AC_MSG_ERROR([Unable to locate required GL library])])
])
Specify the full filename when g_module_open'ing the GL library Instead of using g_module_build_path with the short name of the GL library (eg, "GL") and relying on glib to add the suffix and prefix, the configure script now directly encodes the full name including the version number (eg, "libGL.so.1"). This is necessary because distros don't always install the non-versioned suffix for the library. The GLES libraries are left without the version suffix because it's not clear what should be placed here and I can't find any documentation from Khronos to clarify this. Mesa seems to install a file called libGLESv2.so.2 but the IMG SDK doesn't install any versioned library. There is an example of dynamically loading libGLESv2 in the Chromium source code and that does not use the version suffix even though it does use the version suffix for GL. This implies that it's at least fairly normal to load the unversioned name for GLES. https://bugzilla.gnome.org/show_bug.cgi?id=654593
2011-07-18 13:07:06 -04:00
COGL_GL_LIBNAME="libGL.so.1"
cogl/configure.ac: check when building for win32 This adds a check for when building on win32 so we can skip pkg-config checks for opengl and can add appropriate flags to COGL_EXTRA_{LD,C}FLAGS.
2011-04-19 12:45:26 -04:00
])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
AC_DEFINE([HAVE_COGL_GL], [1], [Have GL for rendering])
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_GL"
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS CLUTTER_COGL_HAS_GL"
])
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
AM_CONDITIONAL([COGL_DRIVER_GL_SUPPORTED], [test "x$enable_gl" = "xyes"])
AM_CONDITIONAL([COGL_DRIVER_GLES_SUPPORTED],
[test "x$enable_gles1" = "xyes" || test "x$enable_gles2" = "xyes"])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
configure: Add configure options to override the GL library name This adds 3 configure options to override the library name that gets dlopened for GL, GLES and GLESv2. This could be useful for distro maintainers who have an unusual name for the libraries (for example, on OpenBSD the GL library appears to be called libGL.so.4). This could at least be simpler than having to create a distro patch. The configure options would be used like this: ./configure --with-gl-libname=libGL.so \ --with-gles1-libname=libGLESv1.so \ --with-gles2-libname=libGLESv2.so https://bugzilla.gnome.org/show_bug.cgi?id=654593
2011-07-18 13:47:44 -04:00
dnl Allow the GL library names to be overridden with configure options
AC_ARG_WITH([gl-libname],
[AS_HELP_STRING([--with-gl-libname],
override the name of the GL library to dlopen)],
[COGL_GL_LIBNAME="$withval"])
AC_ARG_WITH([gles1-libname],
[AS_HELP_STRING([--with-gles1-libname],
override the name of the GLESv1 library to dlopen)],
[COGL_GLES1_LIBNAME="$withval"])
AC_ARG_WITH([gles2-libname],
[AS_HELP_STRING([--with-gles2-libname],
override the name of the GLESv2 library to dlopen)],
[COGL_GLES2_LIBNAME="$withval"])
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
AC_SUBST([COGL_GL_LIBNAME])
AC_SUBST([COGL_GLES1_LIBNAME])
AC_SUBST([COGL_GLES2_LIBNAME])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if test "x$GL_LIBRARY_DIRECTLY_LINKED" = "xyes"; then
AC_DEFINE([HAVE_DIRECTLY_LINKED_GL_LIBRARY], [1],
[Defined if the GL library shouldn't be dlopened])
fi
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
dnl ========================================================
dnl Check window system integration libraries...
dnl ========================================================
AC_ARG_ENABLE(
[glx],
[AC_HELP_STRING([--enable-glx=@<:@no/yes@:>@], [Enable support GLX @<:@default=auto@:>@])],
[],
[AS_IF([test "x$ALLOW_GLX" = "xyes"], [enable_glx=yes], [enable_glx=no])]
)
AS_IF([test "x$enable_glx" = "xyes"],
[
AS_IF([test "x$ALLOW_GLX" != "xyes"],
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
[AC_MSG_ERROR([GLX not supported with this configuration])])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
NEED_XLIB=yes
SUPPORT_GLX=yes
GL_WINSYS_APIS="$GL_WINSYS_APIS glx"
configure: Expose COGL_HAS_GLX_SUPPORT publicly Instead of only exposing COGL_HAS_GLX_SUPPORT internally in config.h we now expose it though the public cogl-defines.h header. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-07-13 06:43:49 -04:00
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_GLX_SUPPORT"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
# We might fall back to DRM for sync-to-vblank on GLX
PKG_CHECK_EXISTS([libdrm],
[
AC_DEFINE([HAVE_DRM], [1], [Have libdrm support])
COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES libdrm"
],
[])
])
AM_CONDITIONAL(SUPPORT_GLX, [test "x$SUPPORT_GLX" = "xyes"])
Add a WGL winsys This adds a full winsys to handle WGL and Win32.
2011-05-09 12:48:50 -04:00
AC_ARG_ENABLE(
[wgl],
[AC_HELP_STRING([--enable-wgl=@<:@no/yes@:>@], [Enable support for WGL @<:@default=auto@:>@])],
[],
[AS_IF([test "x$ALLOW_WGL" = "xyes"], [enable_wgl=yes], [enable_wgl=no])]
)
AS_IF([test "x$enable_wgl" = "xyes"],
[
AS_IF([test "x$ALLOW_WGL" != "xyes"],
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
[AC_MSG_ERROR([WGL not supported with this configuration])])
Add a WGL winsys This adds a full winsys to handle WGL and Win32.
2011-05-09 12:48:50 -04:00
SUPPORT_WGL=yes
GL_WINSYS_APIS="$GL_WINSYS_APIS wgl"
AC_DEFINE([COGL_HAS_WGL_SUPPORT], [1], [Cogl supports OpenGL using the WGL API])
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_WIN32_SUPPORT"
])
AM_CONDITIONAL(SUPPORT_WGL, [test "x$SUPPORT_WGL" = "xyes"])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
EGL_PLATFORM_COUNT=0
AC_ARG_ENABLE(
[null-egl-platform],
[AC_HELP_STRING([--enable-null-egl-platform=@<:@no/yes@:>@], [Enable support for the NULL egl platform @<:@default=no@:>@])],
[],
enable_null_egl_platform=no
)
AS_IF([test "x$enable_null_egl_platform" = "xyes"],
[
EGL_PLATFORM_COUNT=$((EGL_PLATFORM_COUNT+1))
NEED_EGL=yes
EGL_PLATFORMS="$EGL_PLATFORMS null"
cogl/configure.ac: make COGL_HAS_xyz defines public Instead of using AC_DEFINE for the various COGL_HAS_PLATFORM defines this now adds them to the COGL_DEFINES_SYMBOLS variable which gets substituted into the public cogl-defines.h header.
2011-04-18 10:57:32 -04:00
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_EGL_PLATFORM_POWERVR_NULL_SUPPORT"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
])
AM_CONDITIONAL(SUPPORT_EGL_PLATFORM_POWERVR_NULL,
[test "x$enable_null_egl_platform" = "xyes"])
AC_ARG_ENABLE(
[gdl-egl-platform],
[AC_HELP_STRING([--enable-gdl-egl-platform=@<:@no/yes@:>@], [Enable support for the GDL egl platform @<:@default=no@:>@])],
[],
enable_gdl_egl_platform=no
)
AS_IF([test "x$enable_gdl_egl_platform" == "xyes"],
[
EGL_PLATFORM_COUNT=$((EGL_PLATFORM_COUNT+1))
NEED_EGL=yes
EGL_PLATFORMS="$EGL_PLATFORMS gdl"
AC_CHECK_HEADERS(
[libgdl.h],
[],
[
AC_CHECK_HEADERS(
[CE4100/libgdl.h],
egl-gdl: Correctly substitute COGL_CEX100_LIBGDL_PREFIX We weren't defining CLUTTER_CEX100_LIBGDL_PREFIX in the configure.ac and thus failing to compile when selecting the EGL/GDL winsys. Take the opportunity to rename that to COGL_CEX100_LIBGDL_PREFIX https://bugzilla.gnome.org/show_bug.cgi?id=655355
2011-07-22 11:36:54 -04:00
[
egl-gdl: Don't generate cogl-display.h It's not necessary to generate cogl-display.h just for the GDL backend and to change the inclusion of libgdl.h. We can just tweak the include CFLAGS to put /usr/include/CE4100 in the search path when needed. Previously this did not work because of a stay ',' at the end of the COGL_EXTRA_CFLAGS int he configure.ac. This actually simplifies the code, which is always good. This also fixes out of tree builds. https://bugzilla.gnome.org/show_bug.cgi?id=655724 Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-01 10:20:43 -04:00
COGL_EXTRA_CFLAGS="$COGL_EXTRA_CFLAGS -I/usr/include/CE4100"
egl-gdl: Correctly substitute COGL_CEX100_LIBGDL_PREFIX We weren't defining CLUTTER_CEX100_LIBGDL_PREFIX in the configure.ac and thus failing to compile when selecting the EGL/GDL winsys. Take the opportunity to rename that to COGL_CEX100_LIBGDL_PREFIX https://bugzilla.gnome.org/show_bug.cgi?id=655355
2011-07-22 11:36:54 -04:00
],
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
[AC_MSG_ERROR([libgdl.h not found])])
])
egl-gdl: Don't generate cogl-display.h It's not necessary to generate cogl-display.h just for the GDL backend and to change the inclusion of libgdl.h. We can just tweak the include CFLAGS to put /usr/include/CE4100 in the search path when needed. Previously this did not work because of a stay ',' at the end of the COGL_EXTRA_CFLAGS int he configure.ac. This actually simplifies the code, which is always good. This also fixes out of tree builds. https://bugzilla.gnome.org/show_bug.cgi?id=655724 Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-01 10:20:43 -04:00
COGL_EXTRA_LDFLAGS="$COGL_EXTRA_LDFLAGS -lgdl"
egl-gdl: When compiling the GDL platform, you need to link against -lgdl https://bugzilla.gnome.org/show_bug.cgi?id=655355
2011-07-26 10:28:35 -04:00
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_EGL_PLATFORM_GDL_SUPPORT"
])
AM_CONDITIONAL(SUPPORT_EGL_PLATFORM_GDL,
[test "x$enable_gdl_egl_platform" = "xyes"])
Adds wayland support to the cogl EGL winsys Wayland now supports integration via standard eglSurfaces which makes it possible to share more code with other EGL platforms. (though at some point cogl-winsys-egl.c really needs to gain a more formal CoglEGLPlatform abstraction so we can rein back on the amount of #ifdefs we have.)
2011-03-17 15:31:34 -04:00
AC_ARG_ENABLE(
[wayland-egl-platform],
[AC_HELP_STRING([--enable-wayland-egl-platform=@<:@no/yes@:>@], [Enable support for the Wayland egl platform @<:@default=no@:>@])],
[],
enable_wayland_egl_platform=no
)
AS_IF([test "x$enable_wayland_egl_platform" == "xyes"],
[
EGL_PLATFORM_COUNT=$((EGL_PLATFORM_COUNT+1))
NEED_EGL=yes
EGL_PLATFORMS="$EGL_PLATFORMS wayland"
PKG_CHECK_EXISTS([wayland-egl],
[
COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES wayland-egl"
COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES wayland-client"
],
[AC_MSG_ERROR([Unable to locate required wayland libraries])])
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_EGL_PLATFORM_WAYLAND_SUPPORT"
])
AM_CONDITIONAL(SUPPORT_EGL_PLATFORM_WAYLAND,
[test "x$enable_wayland_egl_platform" = "xyes"])
Adds _cogl_wayland_texture_2d_new_from_buffer API This adds internal API to be able to wrap a wayland buffer as a CoglTexture2D. There is a --enable-wayland-egl-server option to decide if Cogl should support this feature and potentially any EGL based winsys could support this through the EGL_KHR_image_base and EGL_WL_bind_display extensions.
2011-05-24 20:37:56 -04:00
AC_ARG_ENABLE(
[wayland-egl-server],
[AC_HELP_STRING([--enable-wayland-egl-server=@<:@no/yes@:>@], [Enable server side wayland support @<:@default=no@:>@])],
[],
enable_wayland_egl_server=no
)
AS_IF([test "x$enable_wayland_egl_server" == "xyes"],
[
NEED_EGL=yes
COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES wayland-server"
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_WAYLAND_EGL_SERVER_SUPPORT"
])
AM_CONDITIONAL(SUPPORT_WAYLAND_EGL_SERVER,
[test "x$enable_wayland_egl_server" = "xyes"])
android: Add support for an EGL/Android winsys The native window type of the EGL/Android winsys is ANativeWinow*. The Android NDK gives you a pointer to this ANativeWindow and you just need to configure that window using the EGLConfig you are choosing when creating the context. This means you have to know the ANativeWindow* window before creating the context. This is solved here by just having a global variable you can set with cogl_android_set_native_window() before creating the context. This is a bit ugly though, and it conceptually belongs to the OnScreen creation to know which ANativeWindow* to use. This would need a "lazy context creation" mechanism, waiting for the user to create the OnScreen to initialize the GL context.
2011-05-16 11:43:30 -04:00
dnl Android EGL platform
AC_ARG_ENABLE(
[android-egl-platform],
[AC_HELP_STRING([--enable-android-egl-platform=@<:@no/yes@:>@], [Enable support for the Android egl platform @<:@default=no@:>@])],
[],
enable_android_egl_platform=no
)
AS_IF([test "x$enable_android_egl_platform" == "xyes"],
[
EGL_PLATFORM_COUNT=$((EGL_PLATFORM_COUNT+1))
NEED_EGL=yes
EGL_PLATFORMS="$EGL_PLATFORMS android"
AC_CHECK_HEADER([android/native_window.h],
[],
[AC_MSG_ERROR([Unable to locate android/native_window.h])])
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_EGL_PLATFORM_ANDROID_SUPPORT"
])
AM_CONDITIONAL(SUPPORT_EGL_PLATFORM_ANDROID,
[test "x$enable_android_egl_platform" = "xyes"])
Adds wayland support to the cogl EGL winsys Wayland now supports integration via standard eglSurfaces which makes it possible to share more code with other EGL platforms. (though at some point cogl-winsys-egl.c really needs to gain a more formal CoglEGLPlatform abstraction so we can rein back on the amount of #ifdefs we have.)
2011-03-17 15:31:34 -04:00
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
dnl This should go last, since it's the default fallback and we need
dnl to check the value of $EGL_PLATFORM_COUNT here.
AC_ARG_ENABLE(
[xlib-egl-platform],
[AC_HELP_STRING([--enable-xlib-egl-platform=@<:@no/yes@:>@], [Enable support for the Xlib egl platform @<:@default=auto@:>@])],
[],
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
AS_IF([test "x$enable_gles1" = "xyes" -o "x$enable_gles2" = "xyes" && test $EGL_PLATFORM_COUNT -eq 0],
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
[enable_xlib_egl_platform=yes], [enable_xlib_egl_platform=no])
)
AS_IF([test "x$enable_xlib_egl_platform" = "xyes"],
[
EGL_PLATFORM_COUNT=$((EGL_PLATFORM_COUNT+1))
NEED_EGL=yes
NEED_XLIB=yes
EGL_PLATFORMS="$EGL_PLATFORMS xlib"
cogl/configure.ac: make COGL_HAS_xyz defines public Instead of using AC_DEFINE for the various COGL_HAS_PLATFORM defines this now adds them to the COGL_DEFINES_SYMBOLS variable which gets substituted into the public cogl-defines.h header.
2011-04-18 10:57:32 -04:00
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_EGL_PLATFORM_POWERVR_X11_SUPPORT"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
])
AM_CONDITIONAL(SUPPORT_EGL_PLATFORM_POWERVR_X11,
[test "x$enable_xlib_egl_platform" = "xyes"])
AS_IF([test $EGL_PLATFORM_COUNT -gt 1],
[AC_MSG_ERROR(['The --enable-*-egl-platform options are currently mutually exclusive'])])
AS_IF([test "x$NEED_EGL" = "xyes" && test "x$EGL_CHECKED" != "xyes"],
[
PKG_CHECK_EXISTS([egl],
[COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES egl"],
[
AC_CHECK_HEADERS(
egl: Make sure to have egl.h included when testing for eglext.h AC_CHECK_HEADER(S) for eglext.h need include egl.h as it may not be done for you. The patch tries to integrate with the previous work to check if GLES/egl.h ir EGL/egl.h should be included for egl.h.
2011-07-22 10:13:44 -04:00
[EGL/egl.h],
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
[],
[AC_MSG_ERROR([Unable to locate required EGL headers])])
egl: Make sure to have egl.h included when testing for eglext.h AC_CHECK_HEADER(S) for eglext.h need include egl.h as it may not be done for you. The patch tries to integrate with the previous work to check if GLES/egl.h ir EGL/egl.h should be included for egl.h.
2011-07-22 10:13:44 -04:00
AC_CHECK_HEADERS(
[EGL/eglext.h],
[],
[AC_MSG_ERROR([Unable to locate required EGL headers])],
[#include <EGL/egl.h>])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
AC_CHECK_LIB(EGL, [eglInitialize],
[COGL_EXTRA_LDFLAGS="$COGL_EXTRA_LDFLAGS -lEGL"],
[AC_MSG_ERROR([Unable to locate required EGL library])])
COGL_EXTRA_LDFLAGS="$COGL_EXTRA_LDFLAGS -lEGL"
]
)
egl: check or EGL/eglext.h While running configure we now check for EGL/eglext.h and if found we will substitute an inclusion in cogl-defines.h.
2011-05-24 16:33:22 -04:00
COGL_EGL_INCLUDES="#include <EGL/egl.h>
#include <EGL/eglext.h>"
AC_SUBST([COGL_EGL_INCLUDES])
])
build: Ensure EGL related variables are defined even when EGL_CHECKED=yes When checking for EGL earlier in the configure script (ie EGL_CHECKED is "yes"), we did not execute some EGL code. Let's split that code in two: - A first part that has a last change to check for EGL - A second one that defines variables and that should always been run in an EGL build
2011-05-12 10:51:01 -04:00
AS_IF([test "x$NEED_EGL" = "xyes"],
[
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
SUPPORT_EGL=yes
GL_WINSYS_APIS="$GL_WINSYS_APIS egl"
cogl/configure.ac: make COGL_HAS_xyz defines public Instead of using AC_DEFINE for the various COGL_HAS_PLATFORM defines this now adds them to the COGL_DEFINES_SYMBOLS variable which gets substituted into the public cogl-defines.h header.
2011-04-18 10:57:32 -04:00
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_EGL_SUPPORT"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
])
build: Ensure EGL related variables are defined even when EGL_CHECKED=yes When checking for EGL earlier in the configure script (ie EGL_CHECKED is "yes"), we did not execute some EGL code. Let's split that code in two: - A first part that has a last change to check for EGL - A second one that defines variables and that should always been run in an EGL build
2011-05-12 10:51:01 -04:00
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
AM_CONDITIONAL(SUPPORT_EGL, [test "x$SUPPORT_EGL" = "xyes"])
dnl ========================================================
dnl Check X11 dependencies if required
dnl ========================================================
AS_IF([test "x$NEED_XLIB" = "xyes"],
[
X11_MODULES="x11 xext xfixes >= xfixes_req_version xdamage xcomposite >= xcomposite_req_version"
PKG_CHECK_MODULES(DUMMY, [$X11_MODULES],
[COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES $X11_MODULES"])
SUPPORT_X11=yes
SUPPORT_XLIB=yes
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_X11"
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_X11_SUPPORT"
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_XLIB"
COGL_DEFINES_SYMBOLS="$COGL_DEFINES_SYMBOLS COGL_HAS_XLIB_SUPPORT"
])
AM_CONDITIONAL(X11_TESTS, [test "x$SUPPORT_X11" = "xyes"])
AM_CONDITIONAL(SUPPORT_X11, [test "x$SUPPORT_X11" = "xyes"])
AM_CONDITIONAL(SUPPORT_XLIB, [test "x$SUPPORT_XLIB" = "xyes"])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ================================================================
dnl Compiler stuff.
dnl ================================================================
AC_PROG_CC
AC_PROG_CPP
AM_PROG_CC_C_O
AC_ISC_POSIX
AC_C_CONST
dnl ================================================================
dnl Libtool stuff.
dnl ================================================================
dnl AC_PROG_LIBTOOL
dnl LIBTOOL="$LIBTOOL --preserve-dup-deps"
LT_PREREQ([2.2.6])
LT_INIT([disable-static])
dnl ================================================================
dnl I18n stuff.
dnl ================================================================
AM_GNU_GETTEXT_VERSION([0.17])
AM_GNU_GETTEXT([external])
GETTEXT_PACKAGE="cogl"
AC_SUBST(GETTEXT_PACKAGE)
AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE,
"$GETTEXT_PACKAGE",
[The prefix for our gettext translation domains.])
AS_ALL_LINGUAS
dnl ================================================================
dnl Documentation stuff.
dnl ================================================================
build: Fix gtkdocize as it needs to parse the GTK_DOC_CHECK line
2011-05-12 07:59:22 -04:00
# gtkdocize greps for ^GTK_DOC_CHECK and parses it, so you need to have
# it on it's own line.
m4_ifdef([GTK_DOC_CHECK], [
GTK_DOC_CHECK([gtk_doc_req_version], [--flavour no-tmpl])
])
build: Enable building the documentation again At least the 1.6.0 documentation. The 2.0 one has been missed by the filter-branch and will be re-added later.
2011-05-06 12:59:00 -04:00
AM_CONDITIONAL([BUILD_GTK_DOC], [test "x$enable_gtk_doc" = "xyes"])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ================================================================
dnl Check for dependency packages.
dnl ================================================================
dnl ============================================================
dnl Check glib dependencies
dnl ============================================================
AM_PATH_GLIB_2_0([glib_req_version],
[have_glib=yes], [have_glib=no],
[gobject gthread gmodule-no-export])
build: Require gobject-2.0 and gmodule-no-export-2.0 Cogl requires gobject and gmodule API, so we need to check for these and add them to the pkg-config files as dependencies, otherwise building Cogl with --as-needed (like modern distributions now do) will cause build errors. https://bugzilla.gnome.org/show_bug.cgi?id=656809 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-08-18 12:17:48 -04:00
AS_IF([test "x$have_glib" = "xno"], AC_MSG_ERROR([gobject-2.0 is required]))
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
build: Require gobject-2.0 and gmodule-no-export-2.0 Cogl requires gobject and gmodule API, so we need to check for these and add them to the pkg-config files as dependencies, otherwise building Cogl with --as-needed (like modern distributions now do) will cause build errors. https://bugzilla.gnome.org/show_bug.cgi?id=656809 Reviewed-by: Robert Bragg <robert@linux.intel.com>
2011-08-18 12:17:48 -04:00
COGL_PKG_REQUIRES="$COGL_PKG_REQUIRES gobject-2.0 gmodule-no-export-2.0"
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
AC_SUBST(COGL_PKG_REQUIRES)
PKG_CHECK_MODULES(COGL_DEP, [$COGL_PKG_REQUIRES])
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
if test -n "$COGL_PKG_REQUIRES_GL"; then
PKG_CHECK_MODULES(COGL_DEP_GL, [$COGL_PKG_REQUIRES_GL])
dnl Strip out the GL libraries from the GL pkg-config files so we can
dnl dynamically load them instead
gl_libs=""
for x in $COGL_DEP_GL_LIBS; do
AS_CASE([$x],
[-lGL], [],
[-lGLESv2], [],
[-lGLESv1_CM], [],
[*], [gl_libs="$gl_libs $x"])
done
COGL_DEP_CFLAGS="$COGL_DEP_CFLAGS $COGL_DEP_CFLAGS_GL"
COGL_DEP_LIBS="$COGL_DEP_LIBS $gl_libs"
fi
build: only have libcogl-pango depend on pango Only cogl-pango needs a dependency on pangocairo so we are now careful to separate the pangocairo pkg-config flags from the others so we can avoid having libcogl builds refer to them. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-02 09:14:06 -04:00
AC_SUBST(COGL_PANGO_PKG_REQUIRES)
PKG_CHECK_MODULES(COGL_PANGO_DEP, [$COGL_PANGO_PKG_REQUIRES])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ================================================================
dnl Misc program dependencies.
dnl ================================================================
AC_PROG_INSTALL
dnl ================================================================
dnl GObject-Introspection check
dnl ================================================================
GOBJECT_INTROSPECTION_CHECK([gi_req_version])
dnl ================================================================
dnl Checks for header files.
dnl ================================================================
AC_PATH_X
AC_HEADER_STDC
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
AC_CHECK_HEADERS(fcntl.h limits.h unistd.h)
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
dnl ================================================================
dnl Checks for library functions.
dnl ================================================================
configure.ac: Add the check for the ffs function When Cogl was sharing Clutter's configure script, it had a check for the ffs function of libc so that it can provide a fallback if it is not available. This fallback was missed in the split out so Cogl would end up always using the fallback.
2011-05-06 12:21:30 -04:00
dnl The 'ffs' function is part of C99 so it isn't always
dnl available. Cogl has a fallback if needed.
AC_CHECK_FUNCS([ffs])
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
dnl ================================================================
dnl What needs to be substituted in other files
dnl ================================================================
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
COGL_DEFINES=""
for x in $COGL_DEFINES_SYMBOLS; do
COGL_DEFINES="$COGL_DEFINES
#define $x 1"
done;
AC_SUBST(COGL_DEFINES)
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
AS_IF([test "x$cogl_gl_headers" = "x"],
[AC_MSG_ERROR([Internal error: no GL header set])])
dnl cogl_gl_headers is a space separate list of headers to
dnl include. We'll now convert them to a single variable with a
dnl #include line for each header
COGL_GL_HEADER_INCLUDES=""
for x in $cogl_gl_headers; do
COGL_GL_HEADER_INCLUDES="$COGL_GL_HEADER_INCLUDES
#include <$x>"
done;
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
AC_SUBST(COGL_GL_HEADER_INCLUDES)
AC_DEFINE([COGL_ENABLE_EXPERIMENTAL_2_0_API], [1],
[Can use Cogl 2.0 API internally])
AC_SUBST(COGL_DEP_CFLAGS)
AC_SUBST(COGL_DEP_LIBS)
build: only have libcogl-pango depend on pango Only cogl-pango needs a dependency on pangocairo so we are now careful to separate the pangocairo pkg-config flags from the others so we can avoid having libcogl builds refer to them. Reviewed-by: Neil Roberts <neil@linux.intel.com>
2011-08-02 09:14:06 -04:00
AC_SUBST(COGL_PANGO_DEP_CFLAGS)
AC_SUBST(COGL_PANGO_DEP_LIBS)
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
AC_SUBST(COGL_EXTRA_CFLAGS)
AC_SUBST(COGL_EXTRA_LDFLAGS)
cogl/configure.ac: AC_SUBST an empty MAINTAINER_CFLAGS For compatibility with the way we build Cogl as part of Clutter we now substitute an empty MAINTAINER_CFLAGS variable. When building Cogl standalone all our extra CFLAGS go through COGL_EXTRA_CFLAGS so the separate MAINTAINER_CFLAGS aren't used, but automake will get confused if a substitution isn't made.
2011-04-19 12:47:57 -04:00
# just for compatability with the clutter build...
MAINTAINER_CFLAGS=
AC_SUBST(MAINTAINER_CFLAGS)
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
AC_OUTPUT(
Makefile
Adds an initial README to the repo
2011-05-06 07:26:15 -04:00
README
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
cogl/Makefile
cogl/cogl-1.0.pc
Make it clearer that the 2.0 API is experimental This explicitly renames the cogl-2.0 reference manual to cogl-2.0-experimental and renames the cogl-2.0 pkg-config file to cogl-2.0-experimental.pc. Hopefully this should avoid miss-understandings.
2011-06-10 13:47:12 -04:00
cogl/cogl-2.0-experimental.pc
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
cogl/cogl-defines.h
consistently refer to cogl-pango as "cogl-pango" This renames the pango directory to cogl-pango and it renames the installed library to libcogl-pango instead of libcoglpango.
2011-05-05 17:04:07 -04:00
cogl-pango/Makefile
cogl-pango/cogl-pango-1.0.pc
Make it clearer that the 2.0 API is experimental This explicitly renames the cogl-2.0 reference manual to cogl-2.0-experimental and renames the cogl-2.0 pkg-config file to cogl-2.0-experimental.pc. Hopefully this should avoid miss-understandings.
2011-06-10 13:47:12 -04:00
cogl-pango/cogl-pango-2.0-experimental.pc
build: Enable building the documentation again At least the 1.6.0 documentation. The 2.0 one has been missed by the filter-branch and will be re-added later.
2011-05-06 12:59:00 -04:00
doc/Makefile
doc/reference/Makefile
doc/reference/cogl/Makefile
doc/reference/cogl/cogl-docs.xml
Make it clearer that the 2.0 API is experimental This explicitly renames the cogl-2.0 reference manual to cogl-2.0-experimental and renames the cogl-2.0 pkg-config file to cogl-2.0-experimental.pc. Hopefully this should avoid miss-understandings.
2011-06-10 13:47:12 -04:00
doc/reference/cogl-2.0-experimental/Makefile
dist: give 2.0 manual unique DOC_MODULE name The experimental 2.0 reference manual was setup with DOC_MODULE name of "cogl" which conflicted with the 1.x API manual. This meant that when running make install for both the reference manuals all the html files would end up bundled together in the same location. The 2.0 API reference now has a DOC_MODULE name of "cogl-2.0-experimental" the corresponding -sections.txt and -docs.xml.in files have also been renamed to match this. Signed-off-by: Neil Roberts <neil@linux.intel.com>
2011-07-05 15:27:07 -04:00
doc/reference/cogl-2.0-experimental/cogl-2.0-experimental-docs.xml
Adds Cogl Hello World and "X11 foreign" example applications This adds a simple standalone Cogl application that can be used to smoke test a standalone build of Cogl without Clutter. This also adds an x11-foreign app that shows how a toolkit can ask Cogl to draw to an X Window that it owns instead of Cogl being responsible for automatically creating and mapping an X Window for CoglOnscreen.
2011-03-17 15:32:54 -04:00
examples/Makefile
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
po/Makefile.in
)
dnl ================================================================
dnl Dah Da!
dnl ================================================================
echo ""
echo "Cogl - $COGL_1_VERSION/$COGL_VERSION (${COGL_RELEASE_STATUS})"
# Global flags
echo ""
echo " • Global:"
echo " Prefix: ${prefix}"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
echo ""
# Features
echo " • Features:"
Dynamically load the GL or GLES library The GL or GLES library is now dynamically loaded by the CoglRenderer so that it can choose between GL, GLES1 and GLES2 at runtime. The library is loaded by the renderer because it needs to be done before calling eglInitialize. There is a new environment variable called COGL_DRIVER to choose between gl, gles1 or gles2. The #ifdefs for HAVE_COGL_GL, HAVE_COGL_GLES and HAVE_COGL_GLES2 have been changed so that they don't assume the ifdefs are mutually exclusive. They haven't been removed entirely so that it's possible to compile the GLES backends without the the enums from the GL headers. When using GLX the winsys additionally dynamically loads libGL because that also contains the GLX API. It can't be linked in directly because that would probably conflict with the GLES API if the EGL is selected. When compiling with EGL support the library links directly to libEGL because it doesn't contain any GL API so it shouldn't have any conflicts. When building for WGL or OSX Cogl still directly links against the GL API so there is a #define in config.h so that Cogl won't try to dlopen the library. Cogl-pango previously had a #ifdef to detect when the GL backend is used so that it can sneakily pass GL_QUADS to cogl_vertex_buffer_draw. This is now changed so that it queries the CoglContext for the backend. However to get this to work Cogl now needs to export the _cogl_context_get_default symbol and cogl-pango needs some extra -I flags to so that it can include cogl-context-private.h
2011-07-07 15:44:56 -04:00
echo " Drivers: ${enabled_drivers}"
configure: Add configure options to override the GL library name This adds 3 configure options to override the library name that gets dlopened for GL, GLES and GLESv2. This could be useful for distro maintainers who have an unusual name for the libraries (for example, on OpenBSD the GL library appears to be called libGL.so.4). This could at least be simpler than having to create a distro patch. The configure options would be used like this: ./configure --with-gl-libname=libGL.so \ --with-gles1-libname=libGLESv1.so \ --with-gles2-libname=libGLESv2.so https://bugzilla.gnome.org/show_bug.cgi?id=654593
2011-07-18 13:47:44 -04:00
AS_IF([test "x$GL_LIBRARY_DIRECTLY_LINKED" != xyes],
[for driver in $enabled_drivers; do
driver=`echo $driver | tr "[gles]" "[GLES]"`
libname=`eval echo \\$COGL_${driver}_LIBNAME`
echo " Library name for $driver: $libname"
done])
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
echo " GL Window System APIs:${GL_WINSYS_APIS}"
if test "x$SUPPORT_EGL" = "xyes"; then
echo " EGL Platforms:${EGL_PLATFORMS}"
Adds _cogl_wayland_texture_2d_new_from_buffer API This adds internal API to be able to wrap a wayland buffer as a CoglTexture2D. There is a --enable-wayland-egl-server option to decide if Cogl should support this feature and potentially any EGL based winsys could support this through the EGL_KHR_image_base and EGL_WL_bind_display extensions.
2011-05-24 20:37:56 -04:00
echo " Wayland compositor support: ${enable_wayland_egl_server}"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
fi
echo " Image backend: ${COGL_IMAGE_BACKEND}"
Make building cogl-pango optional When building for platforms that don't use pango for handling text you may not need the cogl-pango library.
2011-05-05 16:39:40 -04:00
echo " Cogl Pango: ${enable_cogl_pango}"
profile: Adds a --enable-profile option This adds a --enable-profile option which enables uprof based profiling. It was also necessary to fixup a CLUTTER_ENABLE_PROFILING #ifdef in cogl-context.c to renamed COGL_ENABLE_PROFILING instead. By default Cogl doesn't output uprof reports directly, instead it assumes a higher level toolkit will output a report. If you want a report from Cogl you can export COGL_PROFILE_OUTPUT_REPORT=1 before running your app. The latest version of uprof can be fetched from: git://github.com/rib/UProf.git
2011-06-13 05:30:49 -04:00
echo " Profiling: ${enable_profile}"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
# Compiler/Debug related flags
echo ""
echo " • Compiler options:"
echo " Cogl debug: ${enable_debug}"
echo " Compiler flags: ${CFLAGS} ${COGL_EXTRA_CFLAGS}"
cogl/configure.ac: add options to control driver/egl platform This allows more detailed control over the driver and winsys features that Cogl should have. Cogl is designed so it can support multiple window systems simultaneously so we have enable/disable options for the drivers (gl vs gles1 vs gles2) and options for the individual window systems; currently glx and egl. Egl is broken down into an option for each platform.
2011-03-10 10:15:08 -05:00
echo " Linker flags: ${LDFLAGS} ${COGL_EXTRA_LDFLAGS}"
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
# Miscellaneous
echo ""
echo " • Extra:"
build: Enable building the documentation again At least the 1.6.0 documentation. The 2.0 one has been missed by the filter-branch and will be re-added later.
2011-05-06 12:59:00 -04:00
echo " Build API reference: ${enable_gtk_doc}"
Adds the ability to build Cogl standalone This adds an autogen.sh, configure.ac and build/autotool files etc under clutter/cogl and makes some corresponding Makefile.am changes that make it possible to build and install Cogl as a standalone library. Some notable things about this are: A standalone installation of Cogl installs 3 pkg-config files; cogl-1.0.pc, cogl-gl-1.0.pc and cogl-2.0.pc. The second is only for compatibility with what clutter installed though I'm not sure that anything uses it so maybe we could remove it. cogl-1.0.pc is what Clutter would use if it were updated to build against a standalone cogl library. cogl-2.0.pc is what you would use if you were writing a standalone Cogl application. A standalone installation results in two libraries currently, libcogl.so and libcogl-pango.so. Notably we don't include a major number in the sonames because libcogl supports two major API versions; 1.x as used by Clutter and the experimental 2.x API for standalone applications. Parallel installation of later versions e.g. 3.x and beyond will be supportable either with new sonames or if we can maintain ABI then we'll continue to share libcogl.so. The headers are similarly not installed into a directory with a major version number since the same headers are shared to export the 1.x and 2.x APIs (The only difference is that cogl-2.0.pc ensures that -DCOGL_ENABLE_EXPERIMENTAL_2_0_API is used). Parallel installation of later versions is not precluded though since we can either continue sharing or later add a major version suffix.
2011-02-09 21:32:11 -05:00
echo " Build introspection data: ${enable_introspection}"
echo ""
# General warning about experimental features
if test "x$EXPERIMENTAL_CONFIG" = "xyes"; then
echo ""
echo "☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠"
echo " *WARNING*"
echo ""
echo " The stability of your build might be affected by one or more"
echo " experimental configuration options."
echo
echo " experimental options: $EXPERIMENTAL_OPTIONS"
echo "☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠☠"
echo ""
fi
Reference in New Issue Copy Permalink