efl/legacy/edje/configure.ac

648 lines
19 KiB
Plaintext
Raw Normal View History

##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
m4_define([v_maj], [1])
m4_define([v_min], [6])
m4_define([v_mic], [99])
m4_define([v_rev], m4_esyscmd([(svnversion "${SVN_REPO_PATH:-.}" | grep -v '\(export\|Unversioned directory\)' || echo 0) | awk -F : '{printf("%s\n", $1);}' | tr -d ' :MSP\n']))
m4_if(v_rev, [0], [m4_define([v_rev], m4_esyscmd([git log 2> /dev/null | (grep -m1 git-svn-id || echo 0) | sed -e 's/.*@\([0-9]*\).*/\1/' | tr -d '\n']))])
##-- When released, remove the dnl on the below line
dnl m4_undefine([v_rev])
##-- When doing snapshots - change soname. remove dnl on below line
dnl m4_define([relname], [ver-pre-svn-07])
dnl m4_define([v_rel], [-release relname])
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
m4_ifdef([v_rev], [m4_define([v_ver], [v_maj.v_min.v_mic.v_rev])], [m4_define([v_ver], [v_maj.v_min.v_mic])])
m4_define([lt_cur], m4_eval(v_maj + v_min))
m4_define([lt_rev], v_mic)
m4_define([lt_age], v_min)
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
AC_INIT([edje], [v_ver], [enlightenment-devel@lists.sourceforge.net])
AC_PREREQ([2.52])
AC_CONFIG_SRCDIR([configure.ac])
AC_CONFIG_MACRO_DIR([m4])
AC_CONFIG_HEADERS([config.h])
AH_TOP([
#ifndef EFL_CONFIG_H__
#define EFL_CONFIG_H__
])
AH_BOTTOM([
#endif /* EFL_CONFIG_H__ */
])
AM_INIT_AUTOMAKE([1.6 dist-bzip2])
m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])
AC_LIBTOOL_WIN32_DLL
define([AC_LIBTOOL_LANG_CXX_CONFIG], [:])dnl
define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl
AC_PROG_LIBTOOL
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
m4_ifdef([v_rev], , [m4_define([v_rev], [0])])
m4_ifdef([v_rel], , [m4_define([v_rel], [])])
AC_DEFINE_UNQUOTED(VMAJ, [v_maj], [Major version])
AC_DEFINE_UNQUOTED(VMIN, [v_min], [Minor version])
AC_DEFINE_UNQUOTED(VMIC, [v_mic], [Micro version])
AC_DEFINE_UNQUOTED(VREV, [v_rev], [Revison])
version_info="lt_cur:lt_rev:lt_age"
release_info="v_rel"
AC_SUBST(version_info)
AC_SUBST(release_info)
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##--##
VMAJ=v_maj
AC_SUBST(VMAJ)
2010-02-17 11:50:19 -08:00
AC_DEFINE_UNQUOTED([SHARED_LIB_SUFFIX], ["$shrext_cmds"], [Suffix for shared objects])
### Default options with respect to host
AC_CANONICAL_BUILD
AC_CANONICAL_HOST
case "$host_os" in
mingw32ce*)
MODULE_ARCH="$host_os-$host_cpu"
install_vim="no"
have_edje_cc="no"
;;
*)
MODULE_ARCH="$host_os-$host_cpu-v_maj.0.0"
install_vim="yes"
have_edje_cc="yes"
;;
esac
requirement_edje=""
AC_SUBST(MODULE_ARCH)
AC_DEFINE_UNQUOTED(MODULE_ARCH, "${MODULE_ARCH}", "Module architecture")
### Additional options to configure
AC_ARG_ENABLE([amalgamation],
[AC_HELP_STRING([--enable-amalgamation], [enable generation of one single file with all source code in it, helps compiler optimizations.])],
[if test "x${enableval}" = "xyes"; then
do_amalgamation="yes"
else
do_amalgamation="no"
fi
],
[do_amalgamation="no"]
)
2010-02-17 11:50:19 -08:00
AM_CONDITIONAL([EDJE_AMALGAMATION], [test "x${do_amalgamation}" = "xyes"])
EFL_WITH_BIN([edje], [edje-cc], [edje_cc])
EFL_ENABLE_BIN([edje-cc])
EFL_ENABLE_BIN([edje-decc])
EFL_ENABLE_BIN([edje-recc])
EFL_ENABLE_BIN([edje-player])
EFL_ENABLE_BIN([edje-inspector])
welcome edje_external_inspector. this tool is similar to edje_inspector as it uses similar command line and output formats, but instead of acting upon EDJ compiled files, it will use edje EXTERNAL module providers (/usr/lib/edje/modules/*), being able to list modules and their registered types. it is quite useful to know which parameters are exposed, their types and default value (--detail=terse) and also mode information such as flags, min/max/step/accepted/denied and other valuable information (--detail=all). as usual it accepts globs to filter input. example usage: {{{ shell$ edje_external_inspector -t '*anch*' module { name: "elm"; friendly_name: "Elementary"; types { type { name: "elm/anchorblock"; params { string: "style" "default"; string: "text" "some text"; } } type { name: "elm/anchorview"; params { string: "style" "default"; string: "text" "some text"; } } } } shell$ edje_external_inspector --type='*anch*' module { name: "elm"; friendly_name: "Elementary"; types { type { name: "elm/anchorblock"; params { string: "style" "default"; string: "text" "some text"; } } type { name: "elm/anchorview"; params { string: "style" "default"; string: "text" "some text"; } } } } shell$ edje_external_inspector --detail=all 'emo*' module { name: "emotion"; friendly_name: "Emotion"; types { type { name: "emotion"; label: "Emotion"; params { choice: "engine" "xine"; /* flags: REGULAR, choices: "xine" "gstreamer" */ string: "file"; /* flags: REGULAR */ bool: "play" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ double: "position" "0"; /* flags: REGULAR */ bool: "smooth_scale" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ double: "audio_volume" "0.9"; /* flags: REGULAR */ bool: "audio_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "audio_channel" "0"; /* flags: REGULAR */ bool: "video_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "video_channel" "0"; /* flags: REGULAR */ bool: "spu_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "spu_channel" "0"; /* flags: REGULAR */ int: "chapter" "0"; /* flags: REGULAR */ double: "play_speed" "1"; /* flags: REGULAR */ double: "play_length" "0"; /* flags: REGULAR */ } } } } }}} SVN revision: 54999
2010-11-25 15:16:56 -08:00
EFL_ENABLE_BIN([edje-external-inspector])
EFL_ENABLE_BIN([edje-watch])
# Optional EDJE_PROGRAM_CACHE (use much more ram, but increase speed in some cases)
want_edje_program_cache="no"
AC_ARG_ENABLE([edje-program-cache],
[AC_HELP_STRING(
[--enable-edje-program-cache],
[enable EDJE_PROGRAM_CACHE support. [[default=disabled]]]
)],
[want_edje_program_cache=$enableval]
)
2010-02-17 11:50:19 -08:00
AM_CONDITIONAL([EDJE_PROGRAM_CACHE], [test "x${want_edje_program_cache}" = "xyes"])
if test "x${want_edje_program_cache}" = "xyes" ; then
2010-02-17 11:50:19 -08:00
AC_DEFINE([EDJE_PROGRAM_CACHE], [1], [Cache result of program glob matches - this uses up extra ram with the gain of faster program matching])
fi
# Optional EDJE_CALC_CACHE (use more ram, but increase speed by reducing the need to recalculate static stuff)
want_edje_calc_cache="yes"
AC_ARG_ENABLE([edje-calc-cache],
[AC_HELP_STRING(
[--enable-edje-calc-cache],
[enable EDJE_CALC_CACHE support. [[default=disabled]]]
)],
[want_edje_calc_cache=$enableval]
)
2010-02-17 11:50:19 -08:00
AM_CONDITIONAL([EDJE_CALC_CACHE], [test "x${want_edje_calc_cache}" = "xyes"])
if test "x${want_edje_calc_cache}" = "xyes" ; then
2010-02-17 11:50:19 -08:00
AC_DEFINE([EDJE_CALC_CACHE], [1], [Cache result of edje_part_recalc - this uses up extra ram with the gain of reducing CPU usage when edje object are not resized])
fi
# Enable Fixed Point use
want_fixed_point="no"
AC_ARG_ENABLE([fixed-point],
[AC_HELP_STRING(
[--enable-fixed-point],
[reduce use of FPU by using Fixed Point provided by Eina and Eet, [[default=disabled]]]
)],
[want_fixed_point=$enableval]
)
2010-02-17 11:50:19 -08:00
AM_CONDITIONAL([BUILD_EDJE_FP], [test "x${want_fixed_point}" = "xyes"])
if test "x${want_fixed_point}" = "xyes" ; then
2010-02-17 11:50:19 -08:00
AC_DEFINE([BUILD_EDJE_FP], [1], [Use Fixed Point instead of FPU])
fi
install_vim="yes"
AC_ARG_WITH([vim],
[AC_HELP_STRING([--with-vim=DIR], [Location of Vim data files [[autodetect]]])],
[
if test -d "${withval}"; then
vimdir="${withval}"
fi
]
)
if test "x${vimdir}" = "x" ; then
if test -d "${prefix}/share/vim"; then
vimdir="${prefix}/share/vim"
elif test -d "/usr/share/vim"; then
vimdir="/usr/share/vim"
elif test -d "/usr/local/share/vim"; then
vimdir="/usr/local/share/vim"
elif test -d "/opt/share/vim"; then
vimdir="/opt/share/vim"
else
install_vim="no"
fi
fi
AC_MSG_CHECKING([for location of Vim data files])
if test "${install_vim}" = "yes"; then
AC_MSG_RESULT([$vimdir])
else
AC_MSG_RESULT([Not found, EDC syntax file will not be installed])
fi
AC_SUBST(vimdir)
2009-02-19 00:15:23 -08:00
### Checks for programs
AC_PROG_CC
# doxygen program for documentation building
EFL_CHECK_DOXYGEN([build_doc="yes"], [build_doc="no"])
# python
AM_PATH_PYTHON([2.5], , [:])
AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != : ])
# pkg-config
PKG_PROG_PKG_CONFIG
# Check whether pkg-config supports Requires.private
if $PKG_CONFIG --atleast-pkgconfig-version 0.22; then
pkgconfig_requires_private="Requires.private"
else
pkgconfig_requires_private="Requires"
fi
AC_SUBST(pkgconfig_requires_private)
### Checks for libraries
# Evil library for compilation on Windows
EFL_EDJE_BUILD=""
case "$host_os" in
2011-11-16 09:51:42 -08:00
mingw*)
PKG_CHECK_MODULES([EVIL], [evil >= 1.6.99])
2010-02-17 11:50:19 -08:00
AC_DEFINE([HAVE_EVIL], [1], [Set to 1 if Evil library is installed])
2009-02-19 00:15:23 -08:00
requirement_edje="evil ${requirement_edje}"
EFL_EDJE_BUILD="-DEFL_EDJE_BUILD"
;;
esac
AC_SUBST(EFL_EDJE_BUILD)
# Dependencies for the library
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
# Lua pkg-config hack for different naming conventions
have_lua="yes"
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
requirement_lua=""
lua_libs=""
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
PKG_CHECK_MODULES([LUA], [lua >= 5.1.0], requirement_lua="lua",
[PKG_CHECK_MODULES([LUA], [lua5.1 >= 5.1.0], requirement_lua="lua5.1",
[PKG_CHECK_MODULES([LUA], [lua-5.1 >= 5.1.0], requirement_lua="lua-5.1",
[PKG_CHECK_MODULES([LUA], [lua51 >= 5.1.0], requirement_lua="lua51",
2010-06-25 03:12:23 -07:00
[have_lua="no"])])])])
2010-06-23 11:19:10 -07:00
if test "x${have_lua}" = "xno" ; then
AC_MSG_CHECKING([whether lua_newstate() is in liblua])
AC_CHECK_LIB([lua], [lua_newstate],
[
have_lua="yes"
lua_libs="-llua"
],
[have_lua="no"])
AC_MSG_RESULT([${have_lua}])
fi
AC_SUBST(lua_libs)
2010-06-23 11:19:10 -07:00
if test "x${have_lua}" = "xno" ; then
AC_MSG_ERROR([Cannot find lua library. Be sure that you have installed it and set CFLAGS and LDFLAGS correctly])
fi
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
PKG_CHECK_MODULES([MINIMAL],
[
eina >= 1.6.99
eet >= 1.6.99
])
PKG_CHECK_MODULES([EDJE],
[
eina >= 1.6.99
eet >= 1.6.99
evas >= 1.6.99
ecore >= 1.6.99
ecore-evas >= 1.6.99
ecore-file >= 1.6.99
embryo >= 1.6.99
])
EDJE_LIBS="${EDJE_LIBS} ${LUA_LIBS} ${lua_libs}"
EDJE_CFLAGS="${EDJE_CFLAGS} ${LUA_CFLAGS}"
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
requirement_edje="embryo >= 1.6.99 ecore-evas >= 1.6.99 ecore >= 1.6.99 evas >= 1.6.99 eet >= 1.6.99 eina >= 1.6.99 ${requirement_edje}"
From: "Hanspeter Portner" <ventosus@airpost.net> This concerns Ticket #109: Add Lua support for Edje It adds Lua as scripting facility to Edje, letting Embryo untouched. It should be easier to use and be more flexible than Embryo, imho ;-) --- The patch --- Lua 5.1 is used in sandboxed mode. Lua byte code is not platform/architecture independent, Lua code is saved as text in the Edje container and parsed at load time, therefore. The patch goes in two directions 1) Analogous to Embryo for scripting logic, messaging and custom states. The same things are implemented as in Embryo: - messaging from and to C - manual creation of timers, animators, pollers for custom events / animations - manual manipulation of Edje parts by means of the public edje_object_part_* and internal functions and custom states -> those routines are actually implemented as Lua bindings to functions in Edje.h and Ecore.h -> the implementation is done in an object oriented way, so that the interface gives the feel of an object description language, pretty similar to EDC itself -> combining custom states and custom animators allows for fancy animations and transitions, e.g circular/spline translations or complex/conditional transitions, etc. -> this is just the same as Embryo does, but implemented in Lua, so nothing new here, actually 2) Dynamic object creation and manipulation - this interface stems from the 'script_only' objects in Edje. Those objects are a kind of scriptable Edje counterparts to Evas_Smart objects. The infrastructure for Embryo is already there, but has never been used - I added this in Lua and added some first bindings to experiment with - I thought it would be useful to allow for a limited dynamic creation of ui parts - We can create instances of groups from within the same Edje container and use them just like the main Edje object as stated in 1) - And there are some stand-alone bindings to dynamically create Evas_Image, Evas_Table, Evas_Line, Evas_Polygon as examples -> this may be useful to decouple the program from the ui even more, to be able to do things that have to be done in the program itself atm, but actually belong to the user interface, but need dynamic creation of objects or complex interactions -> those objects are manipulated manually with Lua bindings to the corresponding edje_object_* and evas_object_* functions --- Discussion points --- Both stuff in 1) & 2) is functioning, but needs testing, feedback, improvements, ... Stuff in 1) can already fully replace Embryo scripting with Lua scripting. There still is space for improvements/additions, though. Of the stuff in 2), I think it may only make sense to add the dynamic creation of groups defined in the same Edje container. Dynamic creation of other Evas_Objects makes not much sense, as most of them can already be used as Edje parts and be manipulated with custom states (apart from polygons and lines) and it would make the whole theming potentially more programing-like and much more susceptible for errors, etc. Would this be useful, or drop it all? The scripting should be there just for logic, conditionals, custom states and animations, not for a whole dynamic canvas, imho. There is a patch around with EXTERNAL Edje parts. Seems to be a better, faster, more secure way to extend Edje with custom objects. There would be the possibility of precompiling Lua code at compile time (edje_cc) for faster loading, but we would have to patch and run our own Lua version. The Lua parser is pretty fast, though, and using byte-converted/endianness-swapped byte-code does only pay off for Lua chunks of some kilo lines. Byte code also occupies much more space than text in the final Edje container, as it includes debug symbols. --- Cedric and Vincent told me, that the plan was to replace Embryo totally by Lua before the official release of Edje at the end of the year? So it would make sense to bring Lua to svn soon and look how it fits in, test, debug, adapt it further to the themers needs, decide on its final shape, GATHER SOME PEOPLE TO HELP ;-) --- The Lua enhanced Edje is in sync with svn and can be get directly here git clone git://repo.or.cz/edje_lua.git cd edje_lua git checkout -b lua_patch origin/lua_patch or apply the attached patch There are also some examples to show the usage of the things mentioned above - showcase.edj: shows usage of custom animators, custom states, messaging and the script_only object - test.edj: test cases of script usage and bindings (custom states, custom transitions, tween_states, animators, timers, object_parts), but most of it are experimental script_only objects http://didgmo.sourceforge.net/showcase.edj http://didgmo.sourceforge.net/test.edj The source of showcase.edc is attached, too, to just have a glimpse at Lua inside of EDC --- So, what do you guys think? Thanks and sry for the looong mail, hehe ;-) SVN revision: 41802
2009-08-15 19:34:02 -07:00
requirement_edje="${requirement_lua} ${requirement_edje}"
have_ecore_imf="no"
PKG_CHECK_MODULES([ECORE_IMF],
[
ecore-imf >= 1.6.99
ecore-imf-evas >= 1.6.99
],
[
2010-02-17 11:50:19 -08:00
AC_DEFINE([HAVE_ECORE_IMF], [1], [Input Method Support for Edje Entry])
have_ecore_imf="yes"
requirement_edje="ecore-imf-evas >= 1.6.99 ecore-imf >= 1.6.99 ${requirement_edje}"
],
[have_ecore_imf="no"])
PKG_CHECK_MODULES([EIO],
[eio >= 1.6.99],
[
AC_DEFINE([HAVE_EIO], [1], [Eio is available for monitoring file assynchronously])
have_eio="yes"
requirement_edje="eio >= 1.6.99 ${requirement_edje}"
],
[have_eio="no"])
# Enable Multisense use
want_multisense="yes"
AC_ARG_ENABLE([multisense],
[AC_HELP_STRING(
[--enable-multisense],
[multisense provides sound. tone and haptic effects support, [[default=disabled]]]
)],
[want_multisense=$enableval]
)
AM_CONDITIONAL([ENABLE_MULTISENSE], [test "x${want_multisense}" = "xyes"])
##sndfile library
have_sndfile="no"
want_sndfile="auto"
AC_ARG_ENABLE([sndfile],
[AC_HELP_STRING([--disable-sndfile], [disable sndfile support. @<:@default=detect@:>@])],
[want_sndfile=$enableval], [])
if test "x${want_multisense}" = "xyes" -a "x$want_sndfile" != "xno"; then
PKG_CHECK_MODULES([SNDFILE],
[sndfile >= 1.0.21],
[
AC_DEFINE(HAVE_LIBSNDFILE, 1, [sndfile support for Edje])
have_sndfile="yes"
requirement_edje="sndfile >= 1.0.21 ${requirement_edje}"
],
[have_sndfile="no"; want_multisense="no"]
)
if test "x$want_sndfile" = "xyes" -a "x$have_sndfile" = "xno"; then
AC_MSG_ERROR([sndfile support requested, but not found by pkg-config.])
fi
fi
AM_CONDITIONAL([HAVE_LIBSNDFILE], [test "x${have_sndfile}" = "xyes"])
##libremix library
have_libremix="no"
want_libremix="auto"
AC_ARG_ENABLE([remix],
[AC_HELP_STRING([--disable-remix], [disable remix support. @<:@default=detect@:>@])],
[want_libremix=$enableval], [])
if test "x${want_multisense}" = "xyes" -a "x$want_libremix" != "xno"; then
PKG_CHECK_MODULES([REMIX],
[remix >= 0.2.4],
[
AC_DEFINE(HAVE_LIBREMIX, 1, [remix support for Edje])
have_libremix="yes"
requirement_edje="remix >= 0.2.4 ${requirement_edje}"
AC_DEFINE(__REMIX_PLUGIN__, 1, "Set to REMIX Plugin type")
REMIX_PLUGIN_DIR=`pkg-config --variable=libdir remix`"/remix"
AC_SUBST(REMIX_PLUGIN_DIR)
AC_DEFINE_UNQUOTED(REMIX_PLUGIN_DIR, "$REMIX_PLUGIN_DIR", [Set the remix plugin directory])
],
[have_libremix="no"; want_multisense="no"]
)
if test "x$want_libremix" = "xyes" -a "x$have_libremix" = "xno"; then
AC_MSG_ERROR([remix support requested, but not found by pkg-config.])
fi
fi
AM_CONDITIONAL([HAVE_LIBREMIX], [test "x${have_libremix}" = "xyes"])
##vorbis/ogg library
have_vorbis="no"
want_vorbis="auto"
AC_ARG_ENABLE([vorbisenc],
[AC_HELP_STRING([--disable-vorbis], [disable ogg-vorbis support. @<:@default=detect@:>@])],
[want_vorbis=$enableval], [])
if test "x${want_multisense}" = "xyes" -a "x$want_vorbis" != "xno"; then
PKG_CHECK_MODULES([VORBISENC],
[
ogg >= 1.1.4
vorbis >= 1.2.3
vorbisenc >= 1.2.3
],
[
AC_DEFINE(HAVE_VORBIS, 1, [vorbis support for Edje])
have_vorbis="yes"
requirement_edje="ogg >= 1.1.4 vorbis >= 1.2.3 vorbisenc >= 1.2.3 ${requirement_edje}"
],
[have_vorbis="no"; want_multisense="no"]
)
if test "x$want_vorbis" = "xyes" -a "x$have_vorbis" = "xno"; then
AC_MSG_ERROR([vorbisenc support requested, but not found by pkg-config.])
fi
fi
##alsa library
have_alsa_lib="no"
want_alsa_lib="auto"
AC_ARG_ENABLE([alsa],
[AC_HELP_STRING([--disable-alsa], [disable alsa support. @<:@default=detect@:>@])],
[want_alsa_lib=$enableval], [])
if test "x${want_multisense}" = "xyes" -a "x$want_alsa_lib" != "xno"; then
PKG_CHECK_MODULES([ALSA],
[
alsa >= 1.0.21
],
[
AC_DEFINE(HAVE_LIBALSA, 1, [ALSA support for Edje])
have_alsa_lib="yes"
requirement_edje="alsa >= 1.0.21 ${requirement_edje}"
],
[have_alsa_lib="no"; want_multisense="no"]
)
if test "x$want_alsa_lib" = "xyes" -a "x$have_alsa_lib" = "xno"; then
AC_MSG_ERROR([alsa support requested, but not found by pkg-config.])
fi
fi
AM_CONDITIONAL([HAVE_LIBALSA], [test "x${have_alsa_lib}" = "xyes"])
##flac library
have_flac_lib="no"
want_flac_lib="auto"
AC_ARG_ENABLE([flac],
[AC_HELP_STRING([--disable-flac], [disable flac support. @<:@default=detect@:>@])],
[want_flac_lib=$enableval], [])
if test "x${want_multisense}" = "xyes" -a "x$want_flac_lib" != "xno"; then
PKG_CHECK_MODULES([FLAC],
[
flac >= 1.2.1
],
[
AC_DEFINE(HAVE_LIBFLAC, 1, [flac support for Edje])
have_flac_lib="yes"
# disabled because this adds flac include dirs to cflags... and
# FLAC has an assert.h in its include dirs that ends up
# overriding the system assert.h and thus causes all sorts of
# mayhem
#requirement_edje="flac >= 1.2.1 ${requirement_edje}"
],
[have_flac_lib="no"; want_multisense="no"]
)
if test "x$want_flac_lib" = "xyes" -a "x$have_flac_lib" = "xno"; then
AC_MSG_ERROR([flac support requested, but not found by pkg-config.])
fi
fi
if test "x${want_multisense}" = "xyes" ; then
AC_DEFINE([ENABLE_MULTISENSE], [1], [Use Multisense])
fi
AC_SUBST([want_multisense])
# Dependencies for the binaries
if test "x${have_edje_cc}" = "xyes" ; then
PKG_CHECK_MODULES([EDJE_CC],
[ecore-file >= 1.6.99 ecore-evas >= 1.6.99 ecore >= 1.6.99 evas >= 1.6.99 eet >= 1.6.0 eina >= 1.6.99])
EDJE_CC_LIBS="${EDJE_CC_LIBS} ${LUA_LIBS} ${lua_libs}"
fi
AM_CONDITIONAL([BUILD_EPP], [test "x${have_edje_cc}" = "xyes"])
if test "x${have_edje_decc}" = "xyes" ; then
PKG_CHECK_MODULES([EDJE_DECC],
[ecore-file >= 1.6.99 ecore-evas >= 1.6.99 ecore >= 1.6.99 evas >= 1.6.99 eet >= 1.6.99 eina >= 1.6.99])
2004-10-20 23:33:22 -07:00
fi
if test "x${have_edje_player}" = "xyes" ; then
PKG_CHECK_MODULES([EDJE_PLAYER],
[ecore-evas >= 1.6.99 ecore >= 1.6.99 evas >= 1.6.99 eina >= 1.6.99])
fi
if test "x${have_edje_inspector}" = "xyes" ; then
PKG_CHECK_MODULES([EDJE_INSPECTOR],
[ecore-evas >= 1.6.99 ecore >= 1.6.99 evas >= 1.6.99 eina >= 1.6.99])
fi
if test "x${have_edje_external_inspector}" = "xyes" ; then
PKG_CHECK_MODULES([EDJE_EXTERNAL_INSPECTOR],
[ecore >= 1.6.99 evas >= 1.6.99 eina >= 1.6.99])
fi
if test "x${have_edje_watch}" = "xyes" ; then
PKG_CHECK_MODULES([EDJE_WATCH],
[ecore >= 1.6.99 eina >= 1.6.99 eio >= 1.6.99],
[have_edje_watch="yes"],
[have_edje_watch="no"])
fi
AM_CONDITIONAL([BUILD_EDJE_WATCH], [test "x${have_edje_watch}" = "xyes"])
### Checks for header files
AC_CHECK_HEADERS([locale.h sys/resource.h])
EFL_CHECK_PATH_MAX
### Checks for types
### Checks for structures
### Checks for compiler characteristics
AM_PROG_CC_C_O
AC_C_CONST
AC_PROG_CC_STDC
AC_HEADER_STDC
AC_C___ATTRIBUTE__
case "$host_os" in
mingw32ce*)
EDJE_CFLAGS="${EDJE_CFLAGS} -D_WIN32_WCE=0x0420"
;;
esac
2009-02-19 00:15:23 -08:00
### Checks for linker characteristics
lt_enable_auto_import=""
case "$host_os" in
mingw*)
lt_enable_auto_import="-Wl,--enable-auto-import"
;;
esac
AC_SUBST(lt_enable_auto_import)
### Checks for library functions
AC_ISC_POSIX
AC_FUNC_ALLOCA
case "$host_os" in
mingw*)
2010-02-17 11:50:19 -08:00
AC_DEFINE([HAVE_REALPATH], [1], [Define to 1 if you have the `realpath' function.])
;;
*)
AC_CHECK_FUNCS([realpath])
;;
esac
### Unit tests, coverage and benchmarking
EFL_CHECK_TESTS([enable_tests="yes"], [enable_tests="no"])
EFL_CHECK_COVERAGE([${enable_tests}], [enable_coverage="yes"], [enable_coverage="no"])
EDJE_CFLAGS="${EDJE_CFLAGS} ${EFL_COVERAGE_CFLAGS}"
EDJE_LIBS="${EDJE_LIBS} ${EFL_COVERAGE_LIBS}"
if test "x$enable_coverage" = "xyes" ; then
EDJE_CFLAGS="${EDJE_CFLAGS} ${EFL_DEBUG_CFLAGS}"
fi
## Examples
build_examples="no"
AC_ARG_ENABLE([build-examples],
AC_HELP_STRING([--enable-build-examples],
[Enable building examples. This requires extra denpendencies. If you don't have them installed yet, don't build with this option or it will fail. Build again when you have it, overriding the previous installation). @<:@default==disabled@:>@]),
[
if test "x${enableval}" = "xyes" ; then
build_examples="yes"
else
build_examples="no"
fi
],
[build_examples="no"])
AM_CONDITIONAL([BUILD_EXAMPLES], [test "x${build_examples}" = "xyes"])
AC_SUBST(requirement_edje)
AC_OUTPUT([
edje.pc
edje.spec
Makefile
2004-05-12 13:14:18 -07:00
data/Makefile
data/include/Makefile
doc/Makefile
doc/Doxyfile
src/Makefile
src/lib/Makefile
src/bin/Makefile
src/bin/epp/Makefile
src/modules/Makefile
src/modules/alsa_snd_player/Makefile
src/modules/eet_snd_reader/Makefile
src/modules/multisense_factory/Makefile
src/tests/Makefile
utils/Makefile
src/examples/Makefile
])
#####################################################################
## Info
echo
echo
echo
echo "------------------------------------------------------------------------"
echo "$PACKAGE $VERSION"
echo "------------------------------------------------------------------------"
echo
echo "Configuration Options Summary:"
echo
echo " Amalgamation.........: ${do_amalgamation}"
echo " Ecore IMF............: $have_ecore_imf"
echo " Multisense...........: $want_multisense"
if test "x${want_multisense}" = "xyes" ; then
echo " LibRemix.............: $have_libremix"
echo " Libsndfile...........: $have_sndfile"
echo " Ogg/Vorbis...........: $have_vorbis"
echo " LibFLAC..............: $have_flac_lib"
echo " LibALSA..............: $have_alsa_lib"
fi
echo " EDJE_PROGRAM_CACHE...: $want_edje_program_cache"
echo " EDJE_CALC_CACHE......: $want_edje_calc_cache"
echo " Fixed point..........: $want_fixed_point"
welcome edje_external_inspector. this tool is similar to edje_inspector as it uses similar command line and output formats, but instead of acting upon EDJ compiled files, it will use edje EXTERNAL module providers (/usr/lib/edje/modules/*), being able to list modules and their registered types. it is quite useful to know which parameters are exposed, their types and default value (--detail=terse) and also mode information such as flags, min/max/step/accepted/denied and other valuable information (--detail=all). as usual it accepts globs to filter input. example usage: {{{ shell$ edje_external_inspector -t '*anch*' module { name: "elm"; friendly_name: "Elementary"; types { type { name: "elm/anchorblock"; params { string: "style" "default"; string: "text" "some text"; } } type { name: "elm/anchorview"; params { string: "style" "default"; string: "text" "some text"; } } } } shell$ edje_external_inspector --type='*anch*' module { name: "elm"; friendly_name: "Elementary"; types { type { name: "elm/anchorblock"; params { string: "style" "default"; string: "text" "some text"; } } type { name: "elm/anchorview"; params { string: "style" "default"; string: "text" "some text"; } } } } shell$ edje_external_inspector --detail=all 'emo*' module { name: "emotion"; friendly_name: "Emotion"; types { type { name: "emotion"; label: "Emotion"; params { choice: "engine" "xine"; /* flags: REGULAR, choices: "xine" "gstreamer" */ string: "file"; /* flags: REGULAR */ bool: "play" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ double: "position" "0"; /* flags: REGULAR */ bool: "smooth_scale" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ double: "audio_volume" "0.9"; /* flags: REGULAR */ bool: "audio_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "audio_channel" "0"; /* flags: REGULAR */ bool: "video_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "video_channel" "0"; /* flags: REGULAR */ bool: "spu_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "spu_channel" "0"; /* flags: REGULAR */ int: "chapter" "0"; /* flags: REGULAR */ double: "play_speed" "1"; /* flags: REGULAR */ double: "play_length" "0"; /* flags: REGULAR */ } } } } }}} SVN revision: 54999
2010-11-25 15:16:56 -08:00
echo " Documentation........: ${build_doc}"
echo " Tests................: ${enable_tests}"
echo " Coverage.............: ${enable_coverage}"
echo " Examples.............: install:${install_examples} build:${build_examples}"
echo
welcome edje_external_inspector. this tool is similar to edje_inspector as it uses similar command line and output formats, but instead of acting upon EDJ compiled files, it will use edje EXTERNAL module providers (/usr/lib/edje/modules/*), being able to list modules and their registered types. it is quite useful to know which parameters are exposed, their types and default value (--detail=terse) and also mode information such as flags, min/max/step/accepted/denied and other valuable information (--detail=all). as usual it accepts globs to filter input. example usage: {{{ shell$ edje_external_inspector -t '*anch*' module { name: "elm"; friendly_name: "Elementary"; types { type { name: "elm/anchorblock"; params { string: "style" "default"; string: "text" "some text"; } } type { name: "elm/anchorview"; params { string: "style" "default"; string: "text" "some text"; } } } } shell$ edje_external_inspector --type='*anch*' module { name: "elm"; friendly_name: "Elementary"; types { type { name: "elm/anchorblock"; params { string: "style" "default"; string: "text" "some text"; } } type { name: "elm/anchorview"; params { string: "style" "default"; string: "text" "some text"; } } } } shell$ edje_external_inspector --detail=all 'emo*' module { name: "emotion"; friendly_name: "Emotion"; types { type { name: "emotion"; label: "Emotion"; params { choice: "engine" "xine"; /* flags: REGULAR, choices: "xine" "gstreamer" */ string: "file"; /* flags: REGULAR */ bool: "play" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ double: "position" "0"; /* flags: REGULAR */ bool: "smooth_scale" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ double: "audio_volume" "0.9"; /* flags: REGULAR */ bool: "audio_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "audio_channel" "0"; /* flags: REGULAR */ bool: "video_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "video_channel" "0"; /* flags: REGULAR */ bool: "spu_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "spu_channel" "0"; /* flags: REGULAR */ int: "chapter" "0"; /* flags: REGULAR */ double: "play_speed" "1"; /* flags: REGULAR */ double: "play_length" "0"; /* flags: REGULAR */ } } } } }}} SVN revision: 54999
2010-11-25 15:16:56 -08:00
echo "Programs:"
echo
welcome edje_external_inspector. this tool is similar to edje_inspector as it uses similar command line and output formats, but instead of acting upon EDJ compiled files, it will use edje EXTERNAL module providers (/usr/lib/edje/modules/*), being able to list modules and their registered types. it is quite useful to know which parameters are exposed, their types and default value (--detail=terse) and also mode information such as flags, min/max/step/accepted/denied and other valuable information (--detail=all). as usual it accepts globs to filter input. example usage: {{{ shell$ edje_external_inspector -t '*anch*' module { name: "elm"; friendly_name: "Elementary"; types { type { name: "elm/anchorblock"; params { string: "style" "default"; string: "text" "some text"; } } type { name: "elm/anchorview"; params { string: "style" "default"; string: "text" "some text"; } } } } shell$ edje_external_inspector --type='*anch*' module { name: "elm"; friendly_name: "Elementary"; types { type { name: "elm/anchorblock"; params { string: "style" "default"; string: "text" "some text"; } } type { name: "elm/anchorview"; params { string: "style" "default"; string: "text" "some text"; } } } } shell$ edje_external_inspector --detail=all 'emo*' module { name: "emotion"; friendly_name: "Emotion"; types { type { name: "emotion"; label: "Emotion"; params { choice: "engine" "xine"; /* flags: REGULAR, choices: "xine" "gstreamer" */ string: "file"; /* flags: REGULAR */ bool: "play" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ double: "position" "0"; /* flags: REGULAR */ bool: "smooth_scale" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ double: "audio_volume" "0.9"; /* flags: REGULAR */ bool: "audio_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "audio_channel" "0"; /* flags: REGULAR */ bool: "video_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "video_channel" "0"; /* flags: REGULAR */ bool: "spu_mute" "0"; /* flags: REGULAR, false_str: "false", true_str: "true" */ int: "spu_channel" "0"; /* flags: REGULAR */ int: "chapter" "0"; /* flags: REGULAR */ double: "play_speed" "1"; /* flags: REGULAR */ double: "play_length" "0"; /* flags: REGULAR */ } } } } }}} SVN revision: 54999
2010-11-25 15:16:56 -08:00
echo " Build edje_cc................: $have_edje_cc"
echo " Build edje_decc..............: $have_edje_decc"
echo " Build edje_recc..............: $have_edje_recc"
echo " Build edje_player............: $have_edje_player"
echo " Build edje_inspector.........: $have_edje_inspector"
echo " Build edje_external_inspector: $have_edje_external_inspector"
echo " Build edje_watch.............: $have_edje_watch"
echo
echo "Compilation............: make (or gmake)"
echo " CPPFLAGS.............: $CPPFLAGS"
echo " CFLAGS...............: $CFLAGS"
echo " LDFLAGS..............: $LDFLAGS"
echo
echo "Installation...........: make install (as root if needed, with 'su' or 'sudo')"
echo " prefix...............: $prefix"
echo