[weston,v2,17/17] configure: add an option to allow building only the libraries

Submitted by Giulio Camuffo on Dec. 4, 2014, 9:01 p.m.

Details

Message ID 1417726883-8305-18-git-send-email-giuliocamuffo@gmail.com
State Superseded
Headers show

Not browsing as part of any series.

Commit Message

Giulio Camuffo Dec. 4, 2014, 9:01 p.m.
the --enable/disable-weston-binaries emable or disable the creation
of the 'weston', 'weston-launch' and all the binaries that are
installed in $prefix/lib/libexec. This allows, together with
--enable-clients, to only build the libraries, making possible to
build and install different libweston versions at the same time.
---
 Makefile.am  | 15 +++++++++++++++
 configure.ac |  8 ++++++++
 2 files changed, 23 insertions(+)

Patch hide | download patch | download mbox

diff --git a/Makefile.am b/Makefile.am
index 5ca8179..7422298 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -92,6 +92,8 @@  nodist_libweston_la_SOURCES =					\
 
 BUILT_SOURCES += $(nodist_libweston_la_SOURCES)
 
+
+if BUILD_WESTON_BINARIES
 bin_PROGRAMS += weston
 
 weston_LDFLAGS = -export-dynamic
@@ -103,6 +105,7 @@  weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
 weston_SOURCES =					\
 	src/weston.c					\
 	src/text-backend.c
+endif
 
 # Track this dependency explicitly instead of using BUILT_SOURCES.  We
 # add BUILT_SOURCES to CLEANFILES, but we want to keep git-version.h
@@ -158,6 +161,7 @@  libweston_launcher_la_SOURCES = 		\
 	src/weston-launch.h		\
 	src/weston-launcher.h
 
+if BUILD_WESTON_BINARIES
 bin_PROGRAMS += weston-launch
 weston_launch_SOURCES = src/weston-launch.c
 weston_launch_CPPFLAGS = -DBINDIR='"$(bindir)"' -I$(top_srcdir)/libweston
@@ -170,6 +174,7 @@  install-exec-hook:
 	chown root $(DESTDIR)$(bindir)/weston-launch
 	chmod u+s $(DESTDIR)$(bindir)/weston-launch
 endif
+endif # BUILD_WESTON_BINARIES
 
 endif # BUILD_WESTON_LAUNCH
 
@@ -382,6 +387,7 @@  if BUILD_CLIENTS
 
 bin_PROGRAMS += weston-terminal weston-info
 
+if BUILD_WESTON_BINARIES
 libexec_PROGRAMS +=				\
 	weston-desktop-shell			\
 	weston-screenshooter			\
@@ -392,6 +398,7 @@  if ENABLE_IVI_SHELL
 libexec_PROGRAMS +=				\
 	weston-ivi-shell-user-interface
 endif
+endif
 
 demo_clients =					\
 	weston-flower				\
@@ -506,6 +513,7 @@  weston_flower_SOURCES = clients/flower.c
 weston_flower_LDADD = libtoytoolkit.la
 weston_flower_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
 
+if BUILD_WESTON_BINARIES
 weston_screenshooter_SOURCES =				\
 	clients/screenshot.c
 nodist_weston_screenshooter_SOURCES =			\
@@ -513,6 +521,7 @@  nodist_weston_screenshooter_SOURCES =			\
 	protocol/screenshooter-client-protocol.h
 weston_screenshooter_LDADD = $(CLIENT_LIBS) libshared.la
 weston_screenshooter_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
+endif
 
 weston_terminal_SOURCES = clients/terminal.c
 weston_terminal_LDADD = libtoytoolkit.la -lutil
@@ -606,6 +615,7 @@  weston_editor_LDADD = libtoytoolkit.la $(PANGO_LIBS)
 weston_editor_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) $(PANGO_CFLAGS)
 endif
 
+if BUILD_WESTON_BINARIES
 weston_keyboard_SOURCES = clients/keyboard.c
 nodist_weston_keyboard_SOURCES =			\
 	protocol/desktop-shell-client-protocol.h	\
@@ -621,6 +631,7 @@  nodist_weston_simple_im_SOURCES =		\
 	protocol/input-method-client-protocol.h
 weston_simple_im_LDADD = $(CLIENT_LIBS)
 weston_simple_im_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
+endif
 
 weston_info_SOURCES = clients/weston-info.c
 nodist_weston_info_SOURCES =				\
@@ -629,13 +640,16 @@  nodist_weston_info_SOURCES =				\
 weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la
 weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
 
+if BUILD_WESTON_BINARIES
 weston_desktop_shell_SOURCES = clients/desktop-shell.c
 nodist_weston_desktop_shell_SOURCES =			\
 	protocol/desktop-shell-client-protocol.h	\
 	protocol/desktop-shell-protocol.c
 weston_desktop_shell_LDADD = libtoytoolkit.la
 weston_desktop_shell_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
+endif
 
+if BUILD_WESTON_BINARIES
 if ENABLE_IVI_SHELL
 weston_ivi_shell_user_interface_SOURCES = clients/ivi-shell-user-interface.c
 nodist_weston_ivi_shell_user_interface_SOURCES =			\
@@ -646,6 +660,7 @@  nodist_weston_ivi_shell_user_interface_SOURCES =			\
 weston_ivi_shell_user_interface_LDADD = libtoytoolkit.la
 weston_ivi_shell_user_interface_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
 endif
+endif
 
 if BUILD_FULL_GL_CLIENTS
 demo_clients += weston-gears
diff --git a/configure.ac b/configure.ac
index eeab641..5424a85 100644
--- a/configure.ac
+++ b/configure.ac
@@ -352,6 +352,12 @@  PKG_CHECK_MODULES(SYSTEMD_LOGIN_209, [libsystemd-login >= 209],
 AS_IF([test "x$have_systemd_login_209" = "xyes"],
       [AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 209])])
 
+AC_ARG_ENABLE(weston-binaries,
+              AS_HELP_STRING([--enable-weston-binaries],
+                             [build the weston binaries]),,
+              enable_weston_binaries=yes)
+AM_CONDITIONAL(BUILD_WESTON_BINARIES, test x$enable_weston_binaries == xyes)
+
 AC_ARG_ENABLE(weston-launch, [  --enable-weston-launch],, enable_weston_launch=yes)
 AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes)
 if test x$enable_weston_launch == xyes; then
@@ -518,6 +524,8 @@  AC_MSG_RESULT([
 	Native Backend			${WESTON_NATIVE_BACKEND}
 	setuid Install			${enable_setuid_install}
 
+	Buld the weston binaries	${enable_weston_binaries}
+
 	Cairo Renderer			${with_cairo}
 	EGL				${enable_egl}
 	libxkbcommon			${enable_xkbcommon}

Comments

On Thu, Dec 04, 2014 at 11:01:23PM +0200, Giulio Camuffo wrote:
> the --enable/disable-weston-binaries emable or disable the creation
> of the 'weston', 'weston-launch' and all the binaries that are
> installed in $prefix/lib/libexec. This allows, together with
> --enable-clients, to only build the libraries, making possible to
> build and install different libweston versions at the same time.

Splitting out libweston is a revolutionary change, and likely a great
idea.  This is a very well organized patchset for achieving this -
nicely done.  However, this has huge implications for Weston.  In
consulting with daniels about this, it's still unclear whether this is a
direction that Weston should take.

I'm going to defer this for the time being, since this is too large to
go in for 1.7, and because it needs a deeper architectural
consideration.  In particular, we should better understand the
real-world usages that we can expect to see.  With libraries, the
project will be taking on API stability chores and such, as costs, so we
need to understand the benefits we're gaining in return.  I'd encourage
you to post another request-for-comments on this, to help us hash it out
and come to a decision.

daniels suggests one possible compromise would be to hide this behind an
experimental configure switch.  I'm skeptical that this gives us twice
the complexity for half the usefulness, but if you want to press on with
this in the near term, it'd be a possible path forward.

> ---
> Makefile.am  | 15 +++++++++++++++
>  configure.ac |  8 ++++++++
>  2 files changed, 23 insertions(+)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 5ca8179..7422298 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -92,6 +92,8 @@ nodist_libweston_la_SOURCES =					\
>  
>  BUILT_SOURCES += $(nodist_libweston_la_SOURCES)
>  
> +
> +if BUILD_WESTON_BINARIES
>  bin_PROGRAMS += weston
>  
>  weston_LDFLAGS = -export-dynamic
> @@ -103,6 +105,7 @@ weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
>  weston_SOURCES =					\
>  	src/weston.c					\
>  	src/text-backend.c
> +endif
>  
>  # Track this dependency explicitly instead of using BUILT_SOURCES.  We
>  # add BUILT_SOURCES to CLEANFILES, but we want to keep git-version.h
> @@ -158,6 +161,7 @@ libweston_launcher_la_SOURCES = 		\
>  	src/weston-launch.h		\
>  	src/weston-launcher.h
>  
> +if BUILD_WESTON_BINARIES
>  bin_PROGRAMS += weston-launch
>  weston_launch_SOURCES = src/weston-launch.c
>  weston_launch_CPPFLAGS = -DBINDIR='"$(bindir)"' -I$(top_srcdir)/libweston
> @@ -170,6 +174,7 @@ install-exec-hook:
>  	chown root $(DESTDIR)$(bindir)/weston-launch
>  	chmod u+s $(DESTDIR)$(bindir)/weston-launch
>  endif
> +endif # BUILD_WESTON_BINARIES
>  
>  endif # BUILD_WESTON_LAUNCH
>  
> @@ -382,6 +387,7 @@ if BUILD_CLIENTS
>  
>  bin_PROGRAMS += weston-terminal weston-info
>  
> +if BUILD_WESTON_BINARIES
>  libexec_PROGRAMS +=				\
>  	weston-desktop-shell			\
>  	weston-screenshooter			\
> @@ -392,6 +398,7 @@ if ENABLE_IVI_SHELL
>  libexec_PROGRAMS +=				\
>  	weston-ivi-shell-user-interface
>  endif
> +endif
>  
>  demo_clients =					\
>  	weston-flower				\
> @@ -506,6 +513,7 @@ weston_flower_SOURCES = clients/flower.c
>  weston_flower_LDADD = libtoytoolkit.la
>  weston_flower_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  
> +if BUILD_WESTON_BINARIES
>  weston_screenshooter_SOURCES =				\
>  	clients/screenshot.c
>  nodist_weston_screenshooter_SOURCES =			\
> @@ -513,6 +521,7 @@ nodist_weston_screenshooter_SOURCES =			\
>  	protocol/screenshooter-client-protocol.h
>  weston_screenshooter_LDADD = $(CLIENT_LIBS) libshared.la
>  weston_screenshooter_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
> +endif
>  
>  weston_terminal_SOURCES = clients/terminal.c
>  weston_terminal_LDADD = libtoytoolkit.la -lutil
> @@ -606,6 +615,7 @@ weston_editor_LDADD = libtoytoolkit.la $(PANGO_LIBS)
>  weston_editor_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) $(PANGO_CFLAGS)
>  endif
>  
> +if BUILD_WESTON_BINARIES
>  weston_keyboard_SOURCES = clients/keyboard.c
>  nodist_weston_keyboard_SOURCES =			\
>  	protocol/desktop-shell-client-protocol.h	\
> @@ -621,6 +631,7 @@ nodist_weston_simple_im_SOURCES =		\
>  	protocol/input-method-client-protocol.h
>  weston_simple_im_LDADD = $(CLIENT_LIBS)
>  weston_simple_im_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
> +endif
>  
>  weston_info_SOURCES = clients/weston-info.c
>  nodist_weston_info_SOURCES =				\
> @@ -629,13 +640,16 @@ nodist_weston_info_SOURCES =				\
>  weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la
>  weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  
> +if BUILD_WESTON_BINARIES
>  weston_desktop_shell_SOURCES = clients/desktop-shell.c
>  nodist_weston_desktop_shell_SOURCES =			\
>  	protocol/desktop-shell-client-protocol.h	\
>  	protocol/desktop-shell-protocol.c
>  weston_desktop_shell_LDADD = libtoytoolkit.la
>  weston_desktop_shell_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
> +endif
>  
> +if BUILD_WESTON_BINARIES
>  if ENABLE_IVI_SHELL
>  weston_ivi_shell_user_interface_SOURCES = clients/ivi-shell-user-interface.c
>  nodist_weston_ivi_shell_user_interface_SOURCES =			\
> @@ -646,6 +660,7 @@ nodist_weston_ivi_shell_user_interface_SOURCES =			\
>  weston_ivi_shell_user_interface_LDADD = libtoytoolkit.la
>  weston_ivi_shell_user_interface_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  endif
> +endif
>  
>  if BUILD_FULL_GL_CLIENTS
>  demo_clients += weston-gears
> diff --git a/configure.ac b/configure.ac
> index eeab641..5424a85 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -352,6 +352,12 @@ PKG_CHECK_MODULES(SYSTEMD_LOGIN_209, [libsystemd-login >= 209],
>  AS_IF([test "x$have_systemd_login_209" = "xyes"],
>        [AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 209])])
>  
> +AC_ARG_ENABLE(weston-binaries,
> +              AS_HELP_STRING([--enable-weston-binaries],
> +                             [build the weston binaries]),,
> +              enable_weston_binaries=yes)
> +AM_CONDITIONAL(BUILD_WESTON_BINARIES, test x$enable_weston_binaries == xyes)
> +
>  AC_ARG_ENABLE(weston-launch, [  --enable-weston-launch],, enable_weston_launch=yes)
>  AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes)
>  if test x$enable_weston_launch == xyes; then
> @@ -518,6 +524,8 @@ AC_MSG_RESULT([
>  	Native Backend			${WESTON_NATIVE_BACKEND}
>  	setuid Install			${enable_setuid_install}
>  
> +	Buld the weston binaries	${enable_weston_binaries}
> +
>  	Cairo Renderer			${with_cairo}
>  	EGL				${enable_egl}
>  	libxkbcommon			${enable_xkbcommon}
2015-01-27 22:43 GMT+02:00 Bryce Harrington <bryce@osg.samsung.com>:
> On Thu, Dec 04, 2014 at 11:01:23PM +0200, Giulio Camuffo wrote:
>> the --enable/disable-weston-binaries emable or disable the creation
>> of the 'weston', 'weston-launch' and all the binaries that are
>> installed in $prefix/lib/libexec. This allows, together with
>> --enable-clients, to only build the libraries, making possible to
>> build and install different libweston versions at the same time.
>
> Splitting out libweston is a revolutionary change, and likely a great
> idea.  This is a very well organized patchset for achieving this -
> nicely done.  However, this has huge implications for Weston.  In
> consulting with daniels about this, it's still unclear whether this is a
> direction that Weston should take.
>
> I'm going to defer this for the time being, since this is too large to
> go in for 1.7, and because it needs a deeper architectural
> consideration.  In particular, we should better understand the
> real-world usages that we can expect to see.  With libraries, the
> project will be taking on API stability chores and such, as costs, so we
> need to understand the benefits we're gaining in return.  I'd encourage
> you to post another request-for-comments on this, to help us hash it out
> and come to a decision.

Yeah, i wasn't expecting to see it going in 1.7 at this point.
Regarding API stability, the original idea was to keep the current
approach and have different libweston versions be installable
together. After all, i don't see much difference between a plugin for
weston and a user of libweston, from the API point of view, and we
currently break the plugin API at every release.
The only real world usage currently is my own compositor:
https://github.com/giucam/orbital

>
> daniels suggests one possible compromise would be to hide this behind an
> experimental configure switch.  I'm skeptical that this gives us twice
> the complexity for half the usefulness, but if you want to press on with
> this in the near term, it'd be a possible path forward.

That'd be fine for me.


Thanks,
Giulio

>
>> ---
>> Makefile.am  | 15 +++++++++++++++
>>  configure.ac |  8 ++++++++
>>  2 files changed, 23 insertions(+)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 5ca8179..7422298 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -92,6 +92,8 @@ nodist_libweston_la_SOURCES =                                       \
>>
>>  BUILT_SOURCES += $(nodist_libweston_la_SOURCES)
>>
>> +
>> +if BUILD_WESTON_BINARIES
>>  bin_PROGRAMS += weston
>>
>>  weston_LDFLAGS = -export-dynamic
>> @@ -103,6 +105,7 @@ weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
>>  weston_SOURCES =                                     \
>>       src/weston.c                                    \
>>       src/text-backend.c
>> +endif
>>
>>  # Track this dependency explicitly instead of using BUILT_SOURCES.  We
>>  # add BUILT_SOURCES to CLEANFILES, but we want to keep git-version.h
>> @@ -158,6 +161,7 @@ libweston_launcher_la_SOURCES =           \
>>       src/weston-launch.h             \
>>       src/weston-launcher.h
>>
>> +if BUILD_WESTON_BINARIES
>>  bin_PROGRAMS += weston-launch
>>  weston_launch_SOURCES = src/weston-launch.c
>>  weston_launch_CPPFLAGS = -DBINDIR='"$(bindir)"' -I$(top_srcdir)/libweston
>> @@ -170,6 +174,7 @@ install-exec-hook:
>>       chown root $(DESTDIR)$(bindir)/weston-launch
>>       chmod u+s $(DESTDIR)$(bindir)/weston-launch
>>  endif
>> +endif # BUILD_WESTON_BINARIES
>>
>>  endif # BUILD_WESTON_LAUNCH
>>
>> @@ -382,6 +387,7 @@ if BUILD_CLIENTS
>>
>>  bin_PROGRAMS += weston-terminal weston-info
>>
>> +if BUILD_WESTON_BINARIES
>>  libexec_PROGRAMS +=                          \
>>       weston-desktop-shell                    \
>>       weston-screenshooter                    \
>> @@ -392,6 +398,7 @@ if ENABLE_IVI_SHELL
>>  libexec_PROGRAMS +=                          \
>>       weston-ivi-shell-user-interface
>>  endif
>> +endif
>>
>>  demo_clients =                                       \
>>       weston-flower                           \
>> @@ -506,6 +513,7 @@ weston_flower_SOURCES = clients/flower.c
>>  weston_flower_LDADD = libtoytoolkit.la
>>  weston_flower_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>>
>> +if BUILD_WESTON_BINARIES
>>  weston_screenshooter_SOURCES =                               \
>>       clients/screenshot.c
>>  nodist_weston_screenshooter_SOURCES =                        \
>> @@ -513,6 +521,7 @@ nodist_weston_screenshooter_SOURCES =                     \
>>       protocol/screenshooter-client-protocol.h
>>  weston_screenshooter_LDADD = $(CLIENT_LIBS) libshared.la
>>  weston_screenshooter_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>> +endif
>>
>>  weston_terminal_SOURCES = clients/terminal.c
>>  weston_terminal_LDADD = libtoytoolkit.la -lutil
>> @@ -606,6 +615,7 @@ weston_editor_LDADD = libtoytoolkit.la $(PANGO_LIBS)
>>  weston_editor_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS) $(PANGO_CFLAGS)
>>  endif
>>
>> +if BUILD_WESTON_BINARIES
>>  weston_keyboard_SOURCES = clients/keyboard.c
>>  nodist_weston_keyboard_SOURCES =                     \
>>       protocol/desktop-shell-client-protocol.h        \
>> @@ -621,6 +631,7 @@ nodist_weston_simple_im_SOURCES =         \
>>       protocol/input-method-client-protocol.h
>>  weston_simple_im_LDADD = $(CLIENT_LIBS)
>>  weston_simple_im_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>> +endif
>>
>>  weston_info_SOURCES = clients/weston-info.c
>>  nodist_weston_info_SOURCES =                         \
>> @@ -629,13 +640,16 @@ nodist_weston_info_SOURCES =                            \
>>  weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la
>>  weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>>
>> +if BUILD_WESTON_BINARIES
>>  weston_desktop_shell_SOURCES = clients/desktop-shell.c
>>  nodist_weston_desktop_shell_SOURCES =                        \
>>       protocol/desktop-shell-client-protocol.h        \
>>       protocol/desktop-shell-protocol.c
>>  weston_desktop_shell_LDADD = libtoytoolkit.la
>>  weston_desktop_shell_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>> +endif
>>
>> +if BUILD_WESTON_BINARIES
>>  if ENABLE_IVI_SHELL
>>  weston_ivi_shell_user_interface_SOURCES = clients/ivi-shell-user-interface.c
>>  nodist_weston_ivi_shell_user_interface_SOURCES =                     \
>> @@ -646,6 +660,7 @@ nodist_weston_ivi_shell_user_interface_SOURCES =                  \
>>  weston_ivi_shell_user_interface_LDADD = libtoytoolkit.la
>>  weston_ivi_shell_user_interface_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>>  endif
>> +endif
>>
>>  if BUILD_FULL_GL_CLIENTS
>>  demo_clients += weston-gears
>> diff --git a/configure.ac b/configure.ac
>> index eeab641..5424a85 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -352,6 +352,12 @@ PKG_CHECK_MODULES(SYSTEMD_LOGIN_209, [libsystemd-login >= 209],
>>  AS_IF([test "x$have_systemd_login_209" = "xyes"],
>>        [AC_DEFINE([HAVE_SYSTEMD_LOGIN_209], [1], [Have systemd-login >= 209])])
>>
>> +AC_ARG_ENABLE(weston-binaries,
>> +              AS_HELP_STRING([--enable-weston-binaries],
>> +                             [build the weston binaries]),,
>> +              enable_weston_binaries=yes)
>> +AM_CONDITIONAL(BUILD_WESTON_BINARIES, test x$enable_weston_binaries == xyes)
>> +
>>  AC_ARG_ENABLE(weston-launch, [  --enable-weston-launch],, enable_weston_launch=yes)
>>  AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes)
>>  if test x$enable_weston_launch == xyes; then
>> @@ -518,6 +524,8 @@ AC_MSG_RESULT([
>>       Native Backend                  ${WESTON_NATIVE_BACKEND}
>>       setuid Install                  ${enable_setuid_install}
>>
>> +     Buld the weston binaries        ${enable_weston_binaries}
>> +
>>       Cairo Renderer                  ${with_cairo}
>>       EGL                             ${enable_egl}
>>       libxkbcommon                    ${enable_xkbcommon}
On Wed, 28 Jan 2015 11:13:39 +0200
Giulio Camuffo <giuliocamuffo@gmail.com> wrote:

> 2015-01-27 22:43 GMT+02:00 Bryce Harrington <bryce@osg.samsung.com>:
> > On Thu, Dec 04, 2014 at 11:01:23PM +0200, Giulio Camuffo wrote:
> >> the --enable/disable-weston-binaries emable or disable the creation
> >> of the 'weston', 'weston-launch' and all the binaries that are
> >> installed in $prefix/lib/libexec. This allows, together with
> >> --enable-clients, to only build the libraries, making possible to
> >> build and install different libweston versions at the same time.
> >
> > Splitting out libweston is a revolutionary change, and likely a
> > great idea.  This is a very well organized patchset for achieving
> > this - nicely done.  However, this has huge implications for
> > Weston.  In consulting with daniels about this, it's still unclear
> > whether this is a direction that Weston should take.
> >
> > I'm going to defer this for the time being, since this is too large
> > to go in for 1.7, and because it needs a deeper architectural
> > consideration.  In particular, we should better understand the
> > real-world usages that we can expect to see.  With libraries, the
> > project will be taking on API stability chores and such, as costs,
> > so we need to understand the benefits we're gaining in return.  I'd
> > encourage you to post another request-for-comments on this, to help
> > us hash it out and come to a decision.
> 
> Yeah, i wasn't expecting to see it going in 1.7 at this point.
> Regarding API stability, the original idea was to keep the current
> approach and have different libweston versions be installable
> together. After all, i don't see much difference between a plugin for
> weston and a user of libweston, from the API point of view, and we
> currently break the plugin API at every release.
> The only real world usage currently is my own compositor:
> https://github.com/giucam/orbital

Indeed, I proposed the parallel-installability of different versions
exactly so that we can still break the ABI at will. I do not really
believe we can stabilize the ABI before migrating to libweston
architecture, it will (hopefully) happen slowly over time after the
migration, and maybe one day we stop bumping the incompatible-ABI
revision.

I think the idea of libweston is nowadays accepted that it will happen,
but I haven't paid any attention to the details. Priority vs. other
changes is a whole another matter, too.

There is also the proposition from Daniel (in the "where should
project weston go" thread), that every exported symbol should be
documented before the flag day, if I recall correctly. I'm not
completely sure that is realistic as it might postpone the migration
too far. My suggestion would be to not hold up the flag day due to
documentation, but certainly require docs before we make any longer
term stability promises.

> > daniels suggests one possible compromise would be to hide this
> > behind an experimental configure switch.  I'm skeptical that this
> > gives us twice the complexity for half the usefulness, but if you
> > want to press on with this in the near term, it'd be a possible
> > path forward.
> 
> That'd be fine for me.

I'm sceptical about such configure switch too; Giulio, do you think it
would be feasible and not create just more of a mess?


Thanks,
pq
Is there a reason not to just say that libweston must be statically 
linked? That should remove any abi issues. It's just supposed to be a 
set of helper functions to make wayland servers, right?

On 02/05/2015 12:37 AM, Pekka Paalanen wrote:
> On Wed, 28 Jan 2015 11:13:39 +0200
> Giulio Camuffo <giuliocamuffo@gmail.com> wrote:
>
>> 2015-01-27 22:43 GMT+02:00 Bryce Harrington <bryce@osg.samsung.com>:
>>> On Thu, Dec 04, 2014 at 11:01:23PM +0200, Giulio Camuffo wrote:
>>>> the --enable/disable-weston-binaries emable or disable the creation
>>>> of the 'weston', 'weston-launch' and all the binaries that are
>>>> installed in $prefix/lib/libexec. This allows, together with
>>>> --enable-clients, to only build the libraries, making possible to
>>>> build and install different libweston versions at the same time.
>>>
>>> Splitting out libweston is a revolutionary change, and likely a
>>> great idea.  This is a very well organized patchset for achieving
>>> this - nicely done.  However, this has huge implications for
>>> Weston.  In consulting with daniels about this, it's still unclear
>>> whether this is a direction that Weston should take.
>>>
>>> I'm going to defer this for the time being, since this is too large
>>> to go in for 1.7, and because it needs a deeper architectural
>>> consideration.  In particular, we should better understand the
>>> real-world usages that we can expect to see.  With libraries, the
>>> project will be taking on API stability chores and such, as costs,
>>> so we need to understand the benefits we're gaining in return.  I'd
>>> encourage you to post another request-for-comments on this, to help
>>> us hash it out and come to a decision.
>>
>> Yeah, i wasn't expecting to see it going in 1.7 at this point.
>> Regarding API stability, the original idea was to keep the current
>> approach and have different libweston versions be installable
>> together. After all, i don't see much difference between a plugin for
>> weston and a user of libweston, from the API point of view, and we
>> currently break the plugin API at every release.
>> The only real world usage currently is my own compositor:
>> https://github.com/giucam/orbital
>
> Indeed, I proposed the parallel-installability of different versions
> exactly so that we can still break the ABI at will. I do not really
> believe we can stabilize the ABI before migrating to libweston
> architecture, it will (hopefully) happen slowly over time after the
> migration, and maybe one day we stop bumping the incompatible-ABI
> revision.
>
> I think the idea of libweston is nowadays accepted that it will happen,
> but I haven't paid any attention to the details. Priority vs. other
> changes is a whole another matter, too.
>
> There is also the proposition from Daniel (in the "where should
> project weston go" thread), that every exported symbol should be
> documented before the flag day, if I recall correctly. I'm not
> completely sure that is realistic as it might postpone the migration
> too far. My suggestion would be to not hold up the flag day due to
> documentation, but certainly require docs before we make any longer
> term stability promises.
>
>>> daniels suggests one possible compromise would be to hide this
>>> behind an experimental configure switch.  I'm skeptical that this
>>> gives us twice the complexity for half the usefulness, but if you
>>> want to press on with this in the near term, it'd be a possible
>>> path forward.
>>
>> That'd be fine for me.
>
> I'm sceptical about such configure switch too; Giulio, do you think it
> would be feasible and not create just more of a mess?
>
>
> Thanks,
> pq
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
On Thu, 05 Feb 2015 11:10:11 -0800
Bill Spitzak <spitzak@gmail.com> wrote:

> Is there a reason not to just say that libweston must be statically 
> linked? That should remove any abi issues. It's just supposed to be a 
> set of helper functions to make wayland servers, right?

I don't think that works because of the dlopened backends and
renderers. You'd still need to install those per ABI version.


Thanks,
pq
On Thu, Dec 04, 2014 at 11:01:23PM +0200, Giulio Camuffo wrote:
> the --enable/disable-weston-binaries emable or disable the creation
> of the 'weston', 'weston-launch' and all the binaries that are
> installed in $prefix/lib/libexec. This allows, together with
> --enable-clients, to only build the libraries, making possible to
> build and install different libweston versions at the same time.

Prior to 1.7 there was uncertainty whether to have a libweston.  Since
then, the uncertainty has gone away and it sounds like we're now all
more or less in consensus favoring this change?

However, this patchset hasn't yet landed, and there's still some
questions about specifics.

Should we press ahead with an eye towards getting this landed for 1.8?
Or should we postpone and target landing it as soon as the 1.9 tree
opens?

Bryce
2015-05-09 3:15 GMT+03:00 Bryce Harrington <bryce@osg.samsung.com>:
> On Thu, Dec 04, 2014 at 11:01:23PM +0200, Giulio Camuffo wrote:
>> the --enable/disable-weston-binaries emable or disable the creation
>> of the 'weston', 'weston-launch' and all the binaries that are
>> installed in $prefix/lib/libexec. This allows, together with
>> --enable-clients, to only build the libraries, making possible to
>> build and install different libweston versions at the same time.
>
> Prior to 1.7 there was uncertainty whether to have a libweston.  Since
> then, the uncertainty has gone away and it sounds like we're now all
> more or less in consensus favoring this change?
>
> However, this patchset hasn't yet landed, and there's still some
> questions about specifics.
>
> Should we press ahead with an eye towards getting this landed for 1.8?
> Or should we postpone and target landing it as soon as the 1.9 tree
> opens?

I don't think it'd make sense to push it into 1.8 now, it is a rather
big change and may introduce regressions. 1.9 seems a better idea
imho.

>
> Bryce
On Sat, 9 May 2015 10:09:21 +0300
Giulio Camuffo <giuliocamuffo@gmail.com> wrote:

> 2015-05-09 3:15 GMT+03:00 Bryce Harrington <bryce@osg.samsung.com>:
> > On Thu, Dec 04, 2014 at 11:01:23PM +0200, Giulio Camuffo wrote:
> >> the --enable/disable-weston-binaries emable or disable the creation
> >> of the 'weston', 'weston-launch' and all the binaries that are
> >> installed in $prefix/lib/libexec. This allows, together with
> >> --enable-clients, to only build the libraries, making possible to
> >> build and install different libweston versions at the same time.
> >
> > Prior to 1.7 there was uncertainty whether to have a libweston.  Since
> > then, the uncertainty has gone away and it sounds like we're now all
> > more or less in consensus favoring this change?
> >
> > However, this patchset hasn't yet landed, and there's still some
> > questions about specifics.
> >
> > Should we press ahead with an eye towards getting this landed for 1.8?
> > Or should we postpone and target landing it as soon as the 1.9 tree
> > opens?
> 
> I don't think it'd make sense to push it into 1.8 now, it is a rather
> big change and may introduce regressions. 1.9 seems a better idea
> imho.

Yeah, it is far far too late for 1.8.

This is such a big change, that it would be better to land it early in
a development cycle, like before the mid-point to the next alpha. That
would give us more experience on how it works, and if there are
problems, we should have time to fix them properly.


Thanks,
pq
On Mon, May 11, 2015 at 09:27:38AM +0300, Pekka Paalanen wrote:
> On Sat, 9 May 2015 10:09:21 +0300
> Giulio Camuffo <giuliocamuffo@gmail.com> wrote:
> 
> > 2015-05-09 3:15 GMT+03:00 Bryce Harrington <bryce@osg.samsung.com>:
> > > On Thu, Dec 04, 2014 at 11:01:23PM +0200, Giulio Camuffo wrote:
> > >> the --enable/disable-weston-binaries emable or disable the creation
> > >> of the 'weston', 'weston-launch' and all the binaries that are
> > >> installed in $prefix/lib/libexec. This allows, together with
> > >> --enable-clients, to only build the libraries, making possible to
> > >> build and install different libweston versions at the same time.
> > >
> > > Prior to 1.7 there was uncertainty whether to have a libweston.  Since
> > > then, the uncertainty has gone away and it sounds like we're now all
> > > more or less in consensus favoring this change?
> > >
> > > However, this patchset hasn't yet landed, and there's still some
> > > questions about specifics.
> > >
> > > Should we press ahead with an eye towards getting this landed for 1.8?
> > > Or should we postpone and target landing it as soon as the 1.9 tree
> > > opens?
> > 
> > I don't think it'd make sense to push it into 1.8 now, it is a rather
> > big change and may introduce regressions. 1.9 seems a better idea
> > imho.
> 
> Yeah, it is far far too late for 1.8.
> 
> This is such a big change, that it would be better to land it early in
> a development cycle, like before the mid-point to the next alpha. That
> would give us more experience on how it works, and if there are
> problems, we should have time to fix them properly.

Okay, in this case Guilio, in the next couple weeks can you rebase this
to trunk (hopefully there's not a huge amount changed) and re-propose it
on the mailing list?  Hopefully as things are stabilized for the release
we shouldn't see much changing in the repo.

Then, once 1.9 is open we can proceed with getting it landed first thing.

We will also require tests and API documentation.

Bryce
2015-05-16 7:43 GMT+03:00 Bryce Harrington <bryce@osg.samsung.com>:
> On Mon, May 11, 2015 at 09:27:38AM +0300, Pekka Paalanen wrote:
>> On Sat, 9 May 2015 10:09:21 +0300
>> Giulio Camuffo <giuliocamuffo@gmail.com> wrote:
>>
>> > 2015-05-09 3:15 GMT+03:00 Bryce Harrington <bryce@osg.samsung.com>:
>> > > On Thu, Dec 04, 2014 at 11:01:23PM +0200, Giulio Camuffo wrote:
>> > >> the --enable/disable-weston-binaries emable or disable the creation
>> > >> of the 'weston', 'weston-launch' and all the binaries that are
>> > >> installed in $prefix/lib/libexec. This allows, together with
>> > >> --enable-clients, to only build the libraries, making possible to
>> > >> build and install different libweston versions at the same time.
>> > >
>> > > Prior to 1.7 there was uncertainty whether to have a libweston.  Since
>> > > then, the uncertainty has gone away and it sounds like we're now all
>> > > more or less in consensus favoring this change?
>> > >
>> > > However, this patchset hasn't yet landed, and there's still some
>> > > questions about specifics.
>> > >
>> > > Should we press ahead with an eye towards getting this landed for 1.8?
>> > > Or should we postpone and target landing it as soon as the 1.9 tree
>> > > opens?
>> >
>> > I don't think it'd make sense to push it into 1.8 now, it is a rather
>> > big change and may introduce regressions. 1.9 seems a better idea
>> > imho.
>>
>> Yeah, it is far far too late for 1.8.
>>
>> This is such a big change, that it would be better to land it early in
>> a development cycle, like before the mid-point to the next alpha. That
>> would give us more experience on how it works, and if there are
>> problems, we should have time to fix them properly.
>
> Okay, in this case Guilio, in the next couple weeks can you rebase this
> to trunk (hopefully there's not a huge amount changed) and re-propose it
> on the mailing list?  Hopefully as things are stabilized for the release
> we shouldn't see much changing in the repo.

Sure. Actually my branch on github is already on top of master, or almost.


--
Giulio

>
> Then, once 1.9 is open we can proceed with getting it landed first thing.
>
> We will also require tests and API documentation.
>
> Bryce