[PATCH weston v3 06/11] build a libweston.so used by the weston binary
Pekka Paalanen
ppaalanen at gmail.com
Mon Jul 13 07:00:41 PDT 2015
On Sat, 27 Jun 2015 14:07:46 +0300
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> The library is versioned, so a -N is appended to its name, e.g. libweston-1.so.
> The same is done for the pc file, the include and lib/weston dirs.
> This allows multiple libweston versions to be installed together.
> Additionally, a new libweston.pc is introduced in paraller with weston.pc,
> which is used when building a Weston plugin.
> ---
> Makefile.am | 64 +++++++++++++++++++++++++++++++++++------------------
> configure.ac | 5 ++++-
> src/input.c | 2 +-
> src/libweston.pc.in | 12 ++++++++++
> 4 files changed, 60 insertions(+), 23 deletions(-)
> create mode 100644 src/libweston.pc.in
Hi,
seems to work nicely, comments below.
>
> diff --git a/Makefile.am b/Makefile.am
> index b8f7823..fe970ca 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3,7 +3,7 @@ ACLOCAL_AMFLAGS = -I m4
> bin_PROGRAMS =
> noinst_PROGRAMS =
> libexec_PROGRAMS =
> -moduledir = $(libdir)/weston
> +moduledir = $(libdir)/weston-$(ABI_VERSION)
> module_LTLIBRARIES =
> noinst_LTLIBRARIES =
> BUILT_SOURCES =
> @@ -59,26 +59,20 @@ CLEANFILES = weston.ini \
> internal-screenshot-00.png \
> $(BUILT_SOURCES)
>
> -bin_PROGRAMS += weston
> -
> -weston_LDFLAGS = -export-dynamic
> -weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
> -weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
> -weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
> +lib_LTLIBRARIES = libweston- at ABI_VERSION@.la
> +libweston_ at ABI_VERSION@_la_CPPFLAGS = \
> + $(AM_CPPFLAGS) -DIN_WESTON
> +libweston_ at ABI_VERSION@_la_CFLAGS = \
> + $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) \
> + $(LIBUNWIND_CFLAGS)
> +libweston_ at ABI_VERSION@_la_LIBADD = \
> + $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
> $(DLOPEN_LIBS) -lm libshared.la
>
> -weston_SOURCES = \
> +libweston_ at ABI_VERSION@_la_SOURCES = \
> src/git-version.h \
> - src/log.c \
> src/compositor.c \
> src/compositor.h \
> - src/compositor-x11.h \
> - src/compositor-wayland.h \
> - src/compositor-drm.h \
> - src/compositor-headless.h \
> - src/compositor-fbdev.h \
> - src/compositor-rdp.h \
> - src/compositor-rpi.h \
> src/input.c \
> src/data-device.c \
> src/screenshooter.c \
> @@ -93,7 +87,6 @@ weston_SOURCES = \
> src/timeline.c \
> src/timeline.h \
> src/timeline-object.h \
> - src/main.c \
> shared/helpers.h \
> shared/matrix.c \
> shared/matrix.h \
> @@ -101,7 +94,7 @@ weston_SOURCES = \
> shared/platform.h \
> src/weston-egl-ext.h
>
> -nodist_weston_SOURCES = \
> +nodist_libweston_ at ABI_VERSION@_la_SOURCES = \
> protocol/screenshooter-protocol.c \
> protocol/screenshooter-server-protocol.h \
> protocol/text-cursor-position-protocol.c \
> @@ -117,7 +110,28 @@ nodist_weston_SOURCES = \
> protocol/scaler-protocol.c \
> protocol/scaler-server-protocol.h
>
> -BUILT_SOURCES += $(nodist_weston_SOURCES)
> +BUILT_SOURCES += $(nodist_libweston_ at ABI_VERSION@_la_SOURCES)
> +
> +bin_PROGRAMS += weston
> +
> +weston_LDFLAGS = -export-dynamic
> +weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
> +weston_CFLAGS = $(GCC_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
> +weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
> + $(DLOPEN_LIBS) -lm libshared.la \
> + libweston- at ABI_VERSION@.la
> +
> +weston_SOURCES = \
> + src/main.c \
Seems to miss compositor.h, git-version.h.
Other headers that were not in the original weston_SOURCES that main.c
includes are version.h and shared/os-compatibility.h. Should these be
listed, too?
Also compositor.h includes more headers, some of which were mentioned
in the original weston_SOURCES and some were not.
I suppose all should be listed in the proper *_SOURCES variables?
> + src/compositor-x11.h \
> + src/compositor-wayland.h \
> + src/compositor-drm.h \
> + src/compositor-headless.h \
> + src/compositor-fbdev.h \
> + src/compositor-rdp.h \
> + src/compositor-rpi.h \
> + src/log.c \
> + shared/helpers.h
>
> # Track this dependency explicitly instead of using BUILT_SOURCES. We
> # add BUILT_SOURCES to CLEANFILES, but we want to keep git-version.h
> @@ -185,13 +199,21 @@ endif
> endif # BUILD_WESTON_LAUNCH
>
> pkgconfigdir = $(libdir)/pkgconfig
> -pkgconfig_DATA = src/weston.pc
> +pkgconfig_DATA = \
> + weston-$(ABI_VERSION).pc \
> + libweston-$(ABI_VERSION).pc
> +
> +weston-$(ABI_VERSION).pc: src/weston.pc
> + $(AM_V_GEN) cp src/weston.pc weston-$(ABI_VERSION).pc
Now this is a good question: what do we do with plugins?
Will plugins be written for libweston or weston?
I'd tend to think that plugins are written for weston.
Writing plugins for libweston would mean that you can take any
libweston-based compositor and load an arbitrary third-party plugin.
Would we want or need to support such things?
Let's look at the currently installed plugins:
First there are the backends, which we have already decided to become
mostly libweston internal details:
- drm-backend.so
- fbdev-backend.so
- headless-backend.so
- wayland-backend.so
- x11-backend.so
- and more...
Renderers: just gl-renderer.so, which is a libweston internal detail.
Then we have the shells, that would become main executables,
basically:
- desktop-shell.so
- fullscreen-shell.so
- ivi-shell.so
Last, the odd bunch:
- cms-colord.so
- cms-static.so
- hmi-controller.so
- xwayland.so
Color managers. Hmi-controller is an ivi-shell detail, not a weston
plugin. And xwayland, the XWM.
Xwayland has lots of tricky details to get right, which are not really
dependent on the shell. We even have some sort of API for XWM to talk
with the shell already. Therefore it probably makes sense for XWM to
become a runtime-optional part libweston, just like gl-renderer is.
However, XWM has some complications like the need to draw X11 window
decorations, which shells would probably want to do by their own
design. I'm not sure on which side of the libweston boundary
xwayland.so should be.
Color managers are also an open question to me.
Why ponder these things? Because this patch is renaming weston.pc to
weston-$(ABI_VERSION).pc, and I'm trying to figure out if it makes
sense.
OTOH, even though one can have multiple libweston versions installed in
parallel, we do not intend to make multiple Weston versions to be
installable in parallel. In that sense, we should keep weston.pc as is.
If you write a Weston plugin, you use weston.pc, and if you write a
libweston plugin (if such things exist?), you use
libweston-$(ABI_VERSION).pc.
So, I would propose to keep weston.pc as is.
> +
> +libweston-$(ABI_VERSION).pc: src/libweston.pc
> + $(AM_V_GEN) cp src/libweston.pc libweston-$(ABI_VERSION).pc
>
> wayland_sessiondir = $(datadir)/wayland-sessions
> wayland_session_DATA = src/weston.desktop
> dist_wayland_session_DATA = $(wayland_session_DATA)
>
> -westonincludedir = $(includedir)/weston
> +westonincludedir = $(includedir)/weston-$(ABI_VERSION)
> westoninclude_HEADERS = \
> src/version.h \
> src/compositor.h \
> diff --git a/configure.ac b/configure.ac
> index 404418e..f3b63a1 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -31,6 +31,9 @@ AM_SILENT_RULES([yes])
> AC_PROG_CC
> AC_PROG_SED
>
> +ABI_VERSION=1
> +AC_SUBST(ABI_VERSION)
> +
> # Initialize libtool
> LT_PREREQ([2.2])
> LT_INIT([disable-static])
> @@ -504,7 +507,7 @@ if test x$wayland_scanner = x; then
> wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner wayland-scanner`
> fi
>
> -AC_CONFIG_FILES([Makefile src/version.h src/weston.pc])
> +AC_CONFIG_FILES([Makefile src/version.h src/weston.pc src/libweston.pc])
>
> AM_CONDITIONAL([HAVE_GIT_REPO], [test -f $srcdir/.git/logs/HEAD])
>
> diff --git a/src/input.c b/src/input.c
> index 568985f..21ad499 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -1914,7 +1914,7 @@ bind_seat(struct wl_client *client, void *data, uint32_t version, uint32_t id)
> }
>
> #ifdef ENABLE_XKBCOMMON
> -int
> +WL_EXPORT int
> weston_compositor_xkb_init(struct weston_compositor *ec,
> struct xkb_rule_names *names)
> {
> diff --git a/src/libweston.pc.in b/src/libweston.pc.in
> new file mode 100644
> index 0000000..b59bdc9
> --- /dev/null
> +++ b/src/libweston.pc.in
> @@ -0,0 +1,12 @@
> +prefix=@prefix@
> +exec_prefix=@exec_prefix@
> +libdir=@libdir@
> +includedir=@includedir@
> +libexecdir=@libexecdir@
> +pkglibexecdir=${libexecdir}/@PACKAGE@
pkglibexecdir should probably be ABI-versioned, if defined at all?
Would libweston install anything to libexec? Maybe just leave it out.
> +
> +Name: libweston
> +Description: A library to build Wayland compositors
> +Version: @WESTON_VERSION@
> +Libs: -L${libdir} -lweston- at ABI_VERSION@
> +Cflags: -I${includedir} -I${includedir}/weston- at ABI_VERSION@
I'm not sure about the conventions in .pc files, but as libweston is
parallel-installable, it cannot install anything to non-ABI-versioned
paths. This means that -I${includedir} should be unnecessary.
I looked at the list of installed files from my file system, and it
looks good to me.
Thanks,
pq
More information about the wayland-devel
mailing list