[PATCH weston 0/6] Rework libweston versioning, take 2(?)

From: Emil Velikov <***@collabora.com>

v2: Elaborate what is meant with "major ABI versions" (Pekka).

Signed-off-by: Emil Velikov <***@collabora.com>
Reviewed-by: Pekka Paalanen <***@collabora.co.uk> (v1)
---
README | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/README b/README
index 1265ad1..126df4d 100644
--- a/README
+++ b/README
@@ -41,25 +41,25 @@ continue evolving through many Weston releases before it achieves a
stable API and feature completeness.

-API (in)stability and parallel installability
----------------------------------------------
+API/ABI (in)stability and parallel installability
+-------------------------------------------------

As libweston's API surface is huge, it is impossible to get it right
-in one go. Therefore developers reserve the right to break the API
+in one go. Therefore developers reserve the right to break the API/ABI
between every 1.x.0 Weston release (minor version bumps), just like
Weston's plugin API does. For git snapshots of the master branch, the
-API can break any time without warning or version bump.
+API/ABI can break any time without warning or version bump.

Libweston API or ABI will not be broken between Weston's stable
releases 1.x.0 and 1.x.y, where y < 90.

-To make things tolerable for libweston users despite ABI breakages,
+To make things tolerable for libweston users despite API/ABI breakages,
libweston is designed to be perfectly parallel-installable. An
-ABI-version is defined for libweston, and it is bumped for releases as
-needed. Different ABI-versions of libweston can be installed in
-parallel, so that external projects can easily depend on a particular
-ABI-version, and they do not have to fight over which ABI-version is
-installed in a user's system. This allows a user to install many
+API/ABI-version is defined for libweston, and it is bumped for releases as
+needed. Different non-backward compatible ABI versions of libweston can be
+installed in parallel, so that external projects can easily depend on a
+particular ABI-version. Thus they do not have to fight over which ABI-version
+is installed in a user's system. This allows a user to install many
different compositors each requiring a different libweston ABI-version
without tricks or conflicts.

@@ -161,8 +161,9 @@ would be roughly like this:

- and possibly more...

-Everything should be parallel-installable across libweston
-ABI-versions, except those explicitly mentioned.
+Everything should be parallel-installable across libweston major
+ABI-versions (libweston-1.so, libweston-2.so, etc.), except those
+explicitly mentioned.

Weston's build may not sanely allow this yet, but this is the
intention.

--
2.8.2

Pekka Paalanen

2016-07-05 15:01:18 UTC

On Mon, 4 Jul 2016 15:23:50 +0100

Post by Emil Velikov
v2: Elaborate what is meant with "major ABI versions" (Pekka).
---
README | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)

Hi,

I pushed the first two patches:
ad27693..2d01e91 master -> master

Thanks,
pq

Emil Velikov

2016-07-04 14:23:49 UTC

From: Emil Velikov <***@collabora.com>

v2: Rewrap, add a couple of missing words (Pekka).
v3: Use alternative wording (Yong).

Signed-off-by: Emil Velikov <***@collabora.com>
---
README | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/README b/README
index 789755d..1265ad1 100644
--- a/README
+++ b/README
@@ -73,17 +73,17 @@ http://ometer.com/parallel.html
Libweston design goals
----------------------

-The high-level goal of libweston is that what used to be shell plugins
-will be main executables. Instead of launching 'weston' with various
-arguments to choose the shell, one would be launching
-'weston-desktop', 'weston-ivi', 'orbital', etc. The main executable
-(the hosting program) links to libweston for a fundamental compositor
-implementation. Libweston is also intended for use by other projects
-who want to create new "Wayland WMs".
-
-The libweston API/ABI will be separating the shell logic and main
-program from the rest of the "Weston compositor" (libweston
-internals).
+The high-level goal of libweston is to decouple the compositor from
+the shell implementation (what used to be shell plugins).
+
+Thus, instead of launching 'weston' with various arguments to choose the
+shell, one would launch the shell itself, eg. 'weston-desktop',
+'weston-ivi', 'orbital',etc. The main executable (the hosting program)
+will implement the shell, while libweston will be used for a fundamental
+compositor implementation.
+
+Libweston is also intended for use by other project developers who want
+to create new "Wayland WMs".

Details:

--
2.8.2

Yong Bakos

2016-07-09 21:50:11 UTC

Post by Emil Velikov
v2: Rewrap, add a couple of missing words (Pekka).
v3: Use alternative wording (Yong).

Reviewed-by: Yong Bakos <***@humanoriented.com>

Note: If this ends up going through another revision, see the nit
inline below.

yong

Post by Emil Velikov
---
README | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/README b/README
index 789755d..1265ad1 100644
--- a/README
+++ b/README
@@ -73,17 +73,17 @@ http://ometer.com/parallel.html
Libweston design goals
----------------------
-The high-level goal of libweston is that what used to be shell plugins
-will be main executables. Instead of launching 'weston' with various
-arguments to choose the shell, one would be launching
-'weston-desktop', 'weston-ivi', 'orbital', etc. The main executable
-(the hosting program) links to libweston for a fundamental compositor
-implementation. Libweston is also intended for use by other projects
-who want to create new "Wayland WMs".
-
-The libweston API/ABI will be separating the shell logic and main
-program from the rest of the "Weston compositor" (libweston
-internals).
+The high-level goal of libweston is to decouple the compositor from
+the shell implementation (what used to be shell plugins).
+
+Thus, instead of launching 'weston' with various arguments to choose the
+shell, one would launch the shell itself, eg. 'weston-desktop',
+'weston-ivi', 'orbital',etc. The main executable (the hosting program)

'orbital', etc.

Post by Emil Velikov
+will implement the shell, while libweston will be used for a fundamental
+compositor implementation.
+
+Libweston is also intended for use by other project developers who want
+to create new "Wayland WMs".
--
2.8.2
_______________________________________________
wayland-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Emil Velikov

2016-07-04 14:23:52 UTC

Use the documented libweston-$major.so.0.$minor.$patch scheme.

An (almost) identical one is used by GLIB, GTK{2,3}, QT5, json-glib and
others.

v2:
- Use shorter variable names LIBWESTON_{MAJOR,MINOR...}
- Correctly use -version-info.
- Drop unneeded @LIBWESTON_VERSION_MAJOR@ additions.

Signed-off-by: Emil Velikov <***@collabora.com>
---

XXX:
- Should we rename libweston{,-0}.pc.in ?
- Drop the s/LIBWESTON_ABI_VERSION/LIBWESTON_MAJOR/ hunk ?
- Keep the configure libweston_*_version variables shorter ?
- Yes, the LT_VERSION_INFO hunk looks a bit nasty, yet this is what GTK
is doing, once you unraver the 2-3 layers of variables. It works as
expected though, and I'd imagine others are doing a similar trick.

fixup! libweston: use new versioning scheme
---
Makefile.am | 24 ++++++++++++------------
compositor/weston.pc.in | 2 +-
configure.ac | 12 +++++++++---
3 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index b050c60..1c3d553 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,7 +5,7 @@ noinst_PROGRAMS =
libexec_PROGRAMS =
moduledir = $(libdir)/weston
module_LTLIBRARIES =
-libweston_moduledir = $(libdir)/libweston-${LIBWESTON_ABI_VERSION}
+libweston_moduledir = $(libdir)/libweston-$(LIBWESTON_MAJOR)
libweston_module_LTLIBRARIES =
noinst_LTLIBRARIES =
BUILT_SOURCES =
@@ -61,15 +61,15 @@ CLEANFILES = weston.ini \
internal-screenshot-00.png \
$(BUILT_SOURCES)

-lib_LTLIBRARIES = libweston.la
-libweston_la_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
-libweston_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
-libweston_la_LIBADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
+lib_LTLIBRARIES = libweston-@***@.la
+***@LIBWESTON_MAJOR@_la_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
+***@LIBWESTON_MAJOR@_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
+***@LIBWESTON_MAJOR@_la_LIBADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
$(DLOPEN_LIBS) -lm $(CLOCK_GETTIME_LIBS) \
$(LIBINPUT_BACKEND_LIBS) libshared.la
-libweston_la_LDFLAGS = -release ${LIBWESTON_ABI_VERSION}
+***@LIBWESTON_MAJOR@_la_LDFLAGS = -version-info $(LT_VERSION_INFO)

-libweston_la_SOURCES = \
+***@LIBWESTON_MAJOR@la_SOURCES = \
libweston/git-version.h \
libweston/log.c \
libweston/compositor.c \
@@ -121,7 +121,7 @@ systemd_notify_la_SOURCES = \
libweston/compositor.h
endif

-nodist_libweston_la_SOURCES = \
+***@LIBWESTON_MAJOR@_la_SOURCES = \
protocol/weston-screenshooter-protocol.c \
protocol/weston-screenshooter-server-protocol.h \
protocol/text-cursor-position-protocol.c \
@@ -137,7 +137,7 @@ nodist_libweston_la_SOURCES = \
protocol/linux-dmabuf-unstable-v1-protocol.c \
protocol/linux-dmabuf-unstable-v1-server-protocol.h

-BUILT_SOURCES += $(nodist_libweston_la_SOURCES)
+BUILT_SOURCES += $(***@LIBWESTON_MAJOR@_la_SOURCES)

bin_PROGRAMS += weston

@@ -148,7 +148,7 @@ weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON \
weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
$(DLOPEN_LIBS) $(LIBINPUT_BACKEND_LIBS) \
- -lm libshared.la libweston.la
+ -lm libshared.la libweston-@***@.la

weston_SOURCES = \
compositor/main.c \
@@ -225,12 +225,12 @@ endif
endif # BUILD_WESTON_LAUNCH

pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = compositor/weston.pc libweston/libweston-${LIBWESTON_ABI_VERSION}.pc
+pkgconfig_DATA = compositor/weston.pc libweston/libweston-${LIBWESTON_MAJOR}.pc

wayland_sessiondir = $(datadir)/wayland-sessions
dist_wayland_session_DATA = compositor/weston.desktop

-libwestonincludedir = $(includedir)/libweston-${LIBWESTON_ABI_VERSION}
+libwestonincludedir = $(includedir)/libweston-${LIBWESTON_MAJOR}
libwestoninclude_HEADERS = \
libweston/version.h \
libweston/compositor.h \
diff --git a/compositor/weston.pc.in b/compositor/weston.pc.in
index 09e8580..6890a77 100644
--- a/compositor/weston.pc.in
+++ b/compositor/weston.pc.in
@@ -8,5 +8,5 @@ pkglibexecdir=${libexecdir}/@PACKAGE@
Name: Weston Plugin API
Description: Header files for Weston plugin development
Version: @WESTON_VERSION@
-Requires.private: libweston-@LIBWESTON_ABI_VERSION@
+Requires.private: libweston-@LIBWESTON_MAJOR@
Cflags: -I${includedir}/weston
diff --git a/configure.ac b/configure.ac
index 85a475a..be40f10 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,7 +3,9 @@ m4_define([weston_minor_version], [11])
m4_define([weston_micro_version], [90])
m4_define([weston_version],
[weston_major_version.weston_minor_version.weston_micro_version])
-m4_define([libweston_abi_version], [0])
+m4_define([libweston_major_version], [0])
+m4_define([libweston_minor_version], [0])
+m4_define([libweston_patch_version], [0])

AC_PREREQ([2.64])
AC_INIT([weston],
@@ -18,7 +20,11 @@ AC_SUBST([WESTON_VERSION_MAJOR], [weston_major_version])
AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
-AC_SUBST([LIBWESTON_ABI_VERSION], [libweston_abi_version])
+AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+m4_define([lt_current], [libweston_minor_version])
+m4_define([lt_revision], [libweston_patch_version])
+m4_define([lt_age], [libweston_minor_version])
+AC_SUBST([LT_VERSION_INFO], [lt_current:lt_revision:lt_age])

AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_HEADERS([config.h])
@@ -637,7 +643,7 @@ AC_CONFIG_FILES([Makefile libweston/version.h compositor/weston.pc])

# AC_CONFIG_FILES needs the full name when running autoconf, so we need to use
# libweston_abi_version here, and outside [] because of m4 quoting rules
-AC_CONFIG_FILES([libweston/libweston-]libweston_abi_version[.pc:libweston/libweston.pc.in])
+AC_CONFIG_FILES([libweston/libweston-]libweston_major_version[.pc:libweston/libweston.pc.in])

AM_CONDITIONAL([HAVE_GIT_REPO], [test -f $srcdir/.git/logs/HEAD])

--
2.8.2

Quentin Glidic

2016-07-04 14:45:37 UTC

Post by Emil Velikov
Use the documented libweston-$major.so.0.$minor.$patch scheme.
An (almost) identical one is used by GLIB, GTK{2,3}, QT5, json-glib and
others.
- Use shorter variable names LIBWESTON_{MAJOR,MINOR...}
- Correctly use -version-info.
---
- Should we rename libweston{,-0}.pc.in ?
- Drop the s/LIBWESTON_ABI_VERSION/LIBWESTON_MAJOR/ hunk ?
- Keep the configure libweston_*_version variables shorter ?
- Yes, the LT_VERSION_INFO hunk looks a bit nasty, yet this is what GTK
is doing, once you unraver the 2-3 layers of variables. It works as
expected though, and I'd imagine others are doing a similar trick.
fixup! libweston: use new versioning scheme

Looks good. A bit hard to read but I thing you at least build-tested it. :-)

I think you can drop the "v2" part in the commit message, btw.

One last comment inline to make it perfect.

Post by Emil Velikov
---
Makefile.am | 24 ++++++++++++------------
compositor/weston.pc.in | 2 +-
configure.ac | 12 +++++++++---
3 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index b050c60..1c3d553 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,7 +5,7 @@ noinst_PROGRAMS =
libexec_PROGRAMS =
moduledir = $(libdir)/weston
module_LTLIBRARIES =
-libweston_moduledir = $(libdir)/libweston-${LIBWESTON_ABI_VERSION}
+libweston_moduledir = $(libdir)/libweston-$(LIBWESTON_MAJOR)
libweston_module_LTLIBRARIES =
noinst_LTLIBRARIES =
BUILT_SOURCES =
@@ -61,15 +61,15 @@ CLEANFILES = weston.ini \
internal-screenshot-00.png \
$(BUILT_SOURCES)
-lib_LTLIBRARIES = libweston.la
-libweston_la_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
-libweston_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
-libweston_la_LIBADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
$(DLOPEN_LIBS) -lm $(CLOCK_GETTIME_LIBS) \
$(LIBINPUT_BACKEND_LIBS) libshared.la
-libweston_la_LDFLAGS = -release ${LIBWESTON_ABI_VERSION}
-libweston_la_SOURCES = \
libweston/git-version.h \
libweston/log.c \
libweston/compositor.c \
@@ -121,7 +121,7 @@ systemd_notify_la_SOURCES = \
libweston/compositor.h
endif
-nodist_libweston_la_SOURCES = \
protocol/weston-screenshooter-protocol.c \
protocol/weston-screenshooter-server-protocol.h \
protocol/text-cursor-position-protocol.c \
@@ -137,7 +137,7 @@ nodist_libweston_la_SOURCES = \
protocol/linux-dmabuf-unstable-v1-protocol.c \
protocol/linux-dmabuf-unstable-v1-server-protocol.h
-BUILT_SOURCES += $(nodist_libweston_la_SOURCES)
bin_PROGRAMS += weston
@@ -148,7 +148,7 @@ weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON \
weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
$(DLOPEN_LIBS) $(LIBINPUT_BACKEND_LIBS) \
- -lm libshared.la libweston.la
weston_SOURCES = \
compositor/main.c \
@@ -225,12 +225,12 @@ endif
endif # BUILD_WESTON_LAUNCH
pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = compositor/weston.pc libweston/libweston-${LIBWESTON_ABI_VERSION}.pc
+pkgconfig_DATA = compositor/weston.pc libweston/libweston-${LIBWESTON_MAJOR}.pc
wayland_sessiondir = $(datadir)/wayland-sessions
dist_wayland_session_DATA = compositor/weston.desktop
-libwestonincludedir = $(includedir)/libweston-${LIBWESTON_ABI_VERSION}
+libwestonincludedir = $(includedir)/libweston-${LIBWESTON_MAJOR}
libwestoninclude_HEADERS = \
libweston/version.h \
libweston/compositor.h \
diff --git a/compositor/weston.pc.in b/compositor/weston.pc.in
index 09e8580..6890a77 100644
--- a/compositor/weston.pc.in
+++ b/compositor/weston.pc.in
@@ -8,5 +8,5 @@ pkglibexecdir=${libexecdir}/@PACKAGE@
Name: Weston Plugin API
Description: Header files for Weston plugin development
Cflags: -I${includedir}/weston
diff --git a/configure.ac b/configure.ac
index 85a475a..be40f10 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,7 +3,9 @@ m4_define([weston_minor_version], [11])
m4_define([weston_micro_version], [90])
m4_define([weston_version],
[weston_major_version.weston_minor_version.weston_micro_version])
-m4_define([libweston_abi_version], [0])
+m4_define([libweston_major_version], [0])
+m4_define([libweston_minor_version], [0])
+m4_define([libweston_patch_version], [0])
AC_PREREQ([2.64])
AC_INIT([weston],
@@ -18,7 +20,11 @@ AC_SUBST([WESTON_VERSION_MAJOR], [weston_major_version])
AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
-AC_SUBST([LIBWESTON_ABI_VERSION], [libweston_abi_version])
+AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+m4_define([lt_current], [libweston_minor_version])
+m4_define([lt_revision], [libweston_patch_version])
+m4_define([lt_age], [libweston_minor_version])
+AC_SUBST([LT_VERSION_INFO], [lt_current:lt_revision:lt_age])

I had to do the whole version updating script twice to fully understand
that.
Please add a comment saying:
“We use minor as current and age since on ABI/API break/removal we bump
major, so minor will be reset to 0.”
or anything clear.
The confusing thing here is that current and age are not supposed to be
in sync, and current is supposed to be incremented forever.
Except that here, we have a “new lib” on major bump, so current is fine
to be 0 again.

Cheers,

Post by Emil Velikov
AC_CONFIG_AUX_DIR([build-aux])
AC_CONFIG_HEADERS([config.h])
@@ -637,7 +643,7 @@ AC_CONFIG_FILES([Makefile libweston/version.h compositor/weston.pc])
# AC_CONFIG_FILES needs the full name when running autoconf, so we need to use
# libweston_abi_version here, and outside [] because of m4 quoting rules
-AC_CONFIG_FILES([libweston/libweston-]libweston_abi_version[.pc:libweston/libweston.pc.in])
+AC_CONFIG_FILES([libweston/libweston-]libweston_major_version[.pc:libweston/libweston.pc.in])
AM_CONDITIONAL([HAVE_GIT_REPO], [test -f $srcdir/.git/logs/HEAD])

--
Quentin “Sardem FF7” Glidic

Emil Velikov

2016-07-04 16:54:39 UTC

Looks good. A bit hard to read but I thing you at least build-tested it. :-)
I think you can drop the "v2" part in the commit message, btw.

I've noticed that other commits keep their revision history above the
--- line, and thus is present in git log. So I take that it's a nice
to have, but here it's just useless ?

Post by Quentin Glidic
One last comment inline to make it perfect.

Post by Emil Velikov
---
Makefile.am | 24 ++++++++++++------------
compositor/weston.pc.in | 2 +-
configure.ac | 12 +++++++++---
3 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index b050c60..1c3d553 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,7 +5,7 @@ noinst_PROGRAMS =
libexec_PROGRAMS =
moduledir = $(libdir)/weston
module_LTLIBRARIES =
-libweston_moduledir = $(libdir)/libweston-${LIBWESTON_ABI_VERSION}
+libweston_moduledir = $(libdir)/libweston-$(LIBWESTON_MAJOR)
libweston_module_LTLIBRARIES =
noinst_LTLIBRARIES =
BUILT_SOURCES =
@@ -61,15 +61,15 @@ CLEANFILES = weston.ini \
internal-screenshot-00.png \
$(BUILT_SOURCES)
-lib_LTLIBRARIES = libweston.la
-libweston_la_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
-libweston_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
$(LIBUNWIND_CFLAGS)
-libweston_la_LIBADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
$(LIBUNWIND_CFLAGS)
$(LIBUNWIND_LIBS) \
$(DLOPEN_LIBS) -lm $(CLOCK_GETTIME_LIBS) \
$(LIBINPUT_BACKEND_LIBS) libshared.la
-libweston_la_LDFLAGS = -release ${LIBWESTON_ABI_VERSION}
-libweston_la_SOURCES = \
libweston/git-version.h \
libweston/log.c \
libweston/compositor.c \
@@ -121,7 +121,7 @@ systemd_notify_la_SOURCES = \
libweston/compositor.h
endif
-nodist_libweston_la_SOURCES = \
\
protocol/weston-screenshooter-protocol.c \
protocol/weston-screenshooter-server-protocol.h \
protocol/text-cursor-position-protocol.c \
@@ -137,7 +137,7 @@ nodist_libweston_la_SOURCES =
\
protocol/linux-dmabuf-unstable-v1-protocol.c \
protocol/linux-dmabuf-unstable-v1-server-protocol.h
-BUILT_SOURCES += $(nodist_libweston_la_SOURCES)
bin_PROGRAMS += weston
@@ -148,7 +148,7 @@ weston_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
\
weston_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS) $(LIBUNWIND_CFLAGS)
weston_LDADD = $(COMPOSITOR_LIBS) $(LIBUNWIND_LIBS) \
$(DLOPEN_LIBS) $(LIBINPUT_BACKEND_LIBS) \
- -lm libshared.la libweston.la
weston_SOURCES = \
compositor/main.c \
@@ -225,12 +225,12 @@ endif
endif # BUILD_WESTON_LAUNCH
pkgconfigdir = $(libdir)/pkgconfig
-pkgconfig_DATA = compositor/weston.pc
libweston/libweston-${LIBWESTON_ABI_VERSION}.pc
+pkgconfig_DATA = compositor/weston.pc
libweston/libweston-${LIBWESTON_MAJOR}.pc
wayland_sessiondir = $(datadir)/wayland-sessions
dist_wayland_session_DATA = compositor/weston.desktop
-libwestonincludedir = $(includedir)/libweston-${LIBWESTON_ABI_VERSION}
+libwestonincludedir = $(includedir)/libweston-${LIBWESTON_MAJOR}
libwestoninclude_HEADERS = \
libweston/version.h \
libweston/compositor.h \
diff --git a/compositor/weston.pc.in b/compositor/weston.pc.in
index 09e8580..6890a77 100644
--- a/compositor/weston.pc.in
+++ b/compositor/weston.pc.in
@@ -8,5 +8,5 @@ pkglibexecdir=${libexecdir}/@PACKAGE@
Name: Weston Plugin API
Description: Header files for Weston plugin development
Cflags: -I${includedir}/weston
diff --git a/configure.ac b/configure.ac
index 85a475a..be40f10 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,7 +3,9 @@ m4_define([weston_minor_version], [11])
m4_define([weston_micro_version], [90])
m4_define([weston_version],
[weston_major_version.weston_minor_version.weston_micro_version])
-m4_define([libweston_abi_version], [0])
+m4_define([libweston_major_version], [0])
+m4_define([libweston_minor_version], [0])
+m4_define([libweston_patch_version], [0])
AC_PREREQ([2.64])
AC_INIT([weston],
@@ -18,7 +20,11 @@ AC_SUBST([WESTON_VERSION_MAJOR],
[weston_major_version])
AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
-AC_SUBST([LIBWESTON_ABI_VERSION], [libweston_abi_version])
+AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+m4_define([lt_current], [libweston_minor_version])
+m4_define([lt_revision], [libweston_patch_version])
+m4_define([lt_age], [libweston_minor_version])
+AC_SUBST([LT_VERSION_INFO], [lt_current:lt_revision:lt_age])

I had to do the whole version updating script twice to fully understand
that.
“We use minor as current and age since on ABI/API break/removal we bump
major, so minor will be reset to 0.”
or anything clear.

I'm afraid that the whole -version-info still makes little sense over
here, so anything that you/others suggest will go in as-is. If you
prefer we could fully opt the GTK route, making it clearer from
libtool POV. I'm fearful that will end up more confusing for the
maintainer/release person - even the GTK people get it wrong every now
and then.

Post by Quentin Glidic
The confusing thing here is that current and age are not supposed to be in
sync, and current is supposed to be incremented forever.
Except that here, we have a “new lib” on major bump, so current is fine to
be 0 again.

As per above - any suggestions how to make it less confusing are be
appreciated - more inline comments, alternative commit message, etc.

Thanks
Emil

Pekka Paalanen

2016-07-07 09:11:39 UTC

On Mon, 4 Jul 2016 17:54:39 +0100

Looks good. A bit hard to read but I thing you at least build-tested it. :-)
I think you can drop the "v2" part in the commit message, btw.

I've noticed that other commits keep their revision history above the
--- line, and thus is present in git log. So I take that it's a nice
to have, but here it's just useless ?

Hi,

I would tend to err on too much information in the commit message
than too little, so I don't mind at all having the patch revision
log included. It might even answer some questions for a future git
archeologist.

Thanks,
pq

Emil Velikov

2016-07-04 14:23:51 UTC

From: Emil Velikov <***@collabora.com>

Signed-off-by: Emil Velikov <***@collabora.com>
---
Pekka,

There's a couple of things to 'break' - forward and backward
compatibility.

Latter implies changing (removing) certain existing API, while the
former is used in reference to functionality introduced with minor
bumps.

Since people don't always know when the new API is introduced, let alone
bump the version accordingly in configure (and thus package runtime
dependency), things end up badly.

In some subtle cases (the autogenerated headers in wayland) not only is
the new API available, but you end up using it without knowing. And yes,
I fully agree that approach used in wayland is good, but it can cause
subtle breakage.

If weston devs don't want this approach (i.e. adding the ifdef guards
prove too annoying and/or other), then one can just stick with only with
MAJOR. Then the number will ramp quite fast and user will have no way
of knowing/detecting bugfix (patch versions).

From my experience, using the LIBWESTON_API_VERSION alike macros does
not get in the way of development. Yet it's up-to you guys to make the
call.

-Emil
---
README | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)

diff --git a/README b/README
index 126df4d..72e8c7c 100644
--- a/README
+++ b/README
@@ -70,6 +70,52 @@ For more information about parallel installability, see
http://ometer.com/parallel.html

+Versioning scheme
+-----------------
+
+In order to provide consistent, easy to use versioning, libweston
+follows the rules in the Apache Portable Runtime Project
+http://apr.apache.org/versioning.html.
+
+The document provides the full details, with the gist summed below:
+ - Major - backward incompatible changes.
+ - Minor - new backward compatible features.
+ - Patch - internal (implementation specific) fixes.
+
+
+Forward compatibility
+---------------------
+
+In order to ensure prevent subtle breaks with a simple recompile
+(against a newer version), features introduced with minor versions are
+guarded with a LIBWESTON_API_VERSION guard.
+
+For example:
+Libweston v1.1.0 introduces a new entry point weston_ham_sandwich().
+As such it will be annotated as below in the relevant header(s).
+
+#if LIBWESTON_API_VERSION >= 0x0101
+
+bool
+weston_ham_sandwich(void);
+
+#endif
+
+As the user requires the said symbol, they must explicitly set the
+LIBWESTON_API_VERSION macro. By doing so they explicitly state "yes I
+want to use the said version of the library", at which point they should
+also bump the version check in their configure (or equivalent) script.
+
+The LIBWESTON_API_VERSION is of the format 0x$MAJOR$MINOR and does not
+include PATCH version. As mentioned in the Versioning scheme section,
+PATCH does not reflect any user visible API changes, thus should be not
+considered part of the API VERSION.
+
+Similar approach is used by ATK, QT and KDE programs/libraries,
+libjpeg-turbo, GTK, NetworkManager (in a more complex/compherensive
+manner), js17, lz4 and many others.
+
+
Libweston design goals
----------------------

--
2.8.2

Pekka Paalanen

2016-07-05 14:46:36 UTC

On Mon, 4 Jul 2016 15:23:51 +0100

Post by Emil Velikov
---
Pekka,
There's a couple of things to 'break' - forward and backward
compatibility.
Latter implies changing (removing) certain existing API, while the
former is used in reference to functionality introduced with minor
bumps.
Since people don't always know when the new API is introduced, let alone
bump the version accordingly in configure (and thus package runtime
dependency), things end up badly.
In some subtle cases (the autogenerated headers in wayland) not only is
the new API available, but you end up using it without knowing. And yes,
I fully agree that approach used in wayland is good, but it can cause
subtle breakage.
If weston devs don't want this approach (i.e. adding the ifdef guards
prove too annoying and/or other), then one can just stick with only with
MAJOR. Then the number will ramp quite fast and user will have no way
of knowing/detecting bugfix (patch versions).
From my experience, using the LIBWESTON_API_VERSION alike macros does
not get in the way of development. Yet it's up-to you guys to make the
call.
-Emil
---
README | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/README b/README
index 126df4d..72e8c7c 100644
--- a/README
+++ b/README
@@ -70,6 +70,52 @@ For more information about parallel installability, see
http://ometer.com/parallel.html
+Versioning scheme
+-----------------
+
+In order to provide consistent, easy to use versioning, libweston
+follows the rules in the Apache Portable Runtime Project
+http://apr.apache.org/versioning.html.

Hi Emil,

I read that doc, and I fully agree with it now.

Post by Emil Velikov
+
+ - Major - backward incompatible changes.
+ - Minor - new backward compatible features.
+ - Patch - internal (implementation specific) fixes.
+
+
+Forward compatibility
+---------------------
+
+In order to ensure prevent subtle breaks with a simple recompile

Strike "ensure" perhaps?

Post by Emil Velikov
+(against a newer version), features introduced with minor versions are
+guarded with a LIBWESTON_API_VERSION guard.
+
+Libweston v1.1.0 introduces a new entry point weston_ham_sandwich().
+As such it will be annotated as below in the relevant header(s).
+
+#if LIBWESTON_API_VERSION >= 0x0101
+
+bool
+weston_ham_sandwich(void);
+
+#endif
+
+As the user requires the said symbol, they must explicitly set the
+LIBWESTON_API_VERSION macro. By doing so they explicitly state "yes I
+want to use the said version of the library", at which point they should
+also bump the version check in their configure (or equivalent) script.
+
+The LIBWESTON_API_VERSION is of the format 0x$MAJOR$MINOR and does not
+include PATCH version. As mentioned in the Versioning scheme section,
+PATCH does not reflect any user visible API changes, thus should be not
+considered part of the API VERSION.
+
+Similar approach is used by ATK, QT and KDE programs/libraries,
+libjpeg-turbo, GTK, NetworkManager (in a more complex/compherensive
+manner), js17, lz4 and many others.

This is interesting and the very first time I hear about such a scheme.
Obviously I have never used any library that required me to declare
which version I am expecting to use of it at the CPP level.

Also the APR versioning doc says nothing about it, and I couldn't find
any GTK documentation of a similar mechanism. libjpeg-turbo seems to
have something of the sort indeed, however it also defines
JPEG_LIB_VERSION itself, not the user of the library. I suspect there
is some misunderstanding here. I didn't check the others.

We might need this kind of scheme for deprecating things in libwayland,
too.

So, let's see how it works for libweston. I'm in favour of this.

I think we should also have an example for how do this in a
configure.ac nicely, so that you define the version you want to use
just once, and from that it computes:
- which libweston-$N.pc to use, and the version check with it for
pkg-config
- the generation of #define LIBWESTON_API_VERSION into config.h

Btw. is it usual for the *users* to define LIBWESTON_API_VERSION? To me
it sounds like something libweston would define. Users might define
something like REQUIRE_LIBWESTON_API_VERSION, no?

Post by Emil Velikov
+
+
Libweston design goals
----------------------

The one typo(?) and the bikeshedding about the name aside:
Reviewed-by: Pekka Paalanen <***@collabora.co.uk>

Thanks,
pq

Emil Velikov

2016-07-06 12:57:48 UTC

Post by Pekka Paalanen
On Mon, 4 Jul 2016 15:23:51 +0100

Hi Emil,
I read that doc, and I fully agree with it now.

Strike "ensure" perhaps?

Yes, well spotted.

Post by Emil Velikov
+(against a newer version), features introduced with minor versions are is
+guarded with a LIBWESTON_API_VERSION guard.
+
+Libweston v1.1.0 introduces a new entry point weston_ham_sandwich().
+As such it will be annotated as below in the relevant header(s).
+
+#if LIBWESTON_API_VERSION >= 0x0101
+
+bool
+weston_ham_sandwich(void);
+
+#endif
+
+As the user requires the said symbol, they must explicitly set the
+LIBWESTON_API_VERSION macro. By doing so they explicitly state "yes I
+want to use the said version of the library", at which point they should
+also bump the version check in their configure (or equivalent) script.
+
+The LIBWESTON_API_VERSION is of the format 0x$MAJOR$MINOR and does not
+include PATCH version. As mentioned in the Versioning scheme section,
+PATCH does not reflect any user visible API changes, thus should be not
+considered part of the API VERSION.
+
+Similar approach is used by ATK, QT and KDE programs/libraries,
+libjpeg-turbo, GTK, NetworkManager (in a more complex/compherensive
+manner), js17, lz4 and many others.

Neither have I found any reference/docs on the topic sadly.

Post by Pekka Paalanen
and I couldn't find
any GTK documentation of a similar mechanism. libjpeg-turbo seems to
have something of the sort indeed, however it also defines
JPEG_LIB_VERSION itself, not the user of the library. I suspect there
is some misunderstanding here. I didn't check the others.

On the libjpeg-turbo front, JPEG_LIB_VERSION is _optionally_ defined
and controls only the structs' layout.

On the GTK side I've made a typo - it should have been GDK.
Here is a snippet from /usr/include/gtk-3.0/gdk/gdkversionmacros.h

/**
* GDK_VERSION_MAX_ALLOWED:
*
* A macro that should be defined by the user prior to including
* the gdk.h header.
* The definition should be one of the predefined GDK version
* macros: %GDK_VERSION_3_0, %GDK_VERSION_3_2,...
*
* This macro defines the upper bound for the GDK API to use.
*
* If a function has been introduced in a newer version of GDK,
* it is possible to use this symbol to get compiler warnings when
* trying to use that function.
*
* Since: 3.4
*/

Obviously the exact method (define upper/lower/other limit) and
effects (warn, hide, error) differ between libraries but the overall
idea is there.

That said, I could have misunderstood something.

Post by Pekka Paalanen
We might need this kind of scheme for deprecating things in libwayland,
too.

Yes, I was hoping to get to that at some point.

Post by Pekka Paalanen
So, let's see how it works for libweston. I'm in favour of this.
I think we should also have an example for how do this in a
configure.ac nicely, so that you define the version you want to use
- which libweston-$N.pc to use, and the version check with it for
pkg-config
- the generation of #define LIBWESTON_API_VERSION into config.h

Ack. I'll add a snippet of how the configure changes should look.

Post by Pekka Paalanen
Btw. is it usual for the *users* to define LIBWESTON_API_VERSION? To me
it sounds like something libweston would define. Users might define
something like REQUIRE_LIBWESTON_API_VERSION, no?

The name I chose is causing some confusion.
REQUIRE_LIBWESTON_API_VERSION sounds a lot better.

Post by Emil Velikov
+
+
Libweston design goals
----------------------

Thanks
Emil

Pekka Paalanen

2016-07-07 09:05:14 UTC

On Wed, 6 Jul 2016 13:57:48 +0100

Post by Pekka Paalanen
On Mon, 4 Jul 2016 15:23:51 +0100

Hi Emil,
I read that doc, and I fully agree with it now.

Strike "ensure" perhaps?

Yes, well spotted.

Neither have I found any reference/docs on the topic sadly.

On the libjpeg-turbo front, JPEG_LIB_VERSION is _optionally_ defined
and controls only the structs' layout.
On the GTK side I've made a typo - it should have been GDK.
Here is a snippet from /usr/include/gtk-3.0/gdk/gdkversionmacros.h
/**
*
* A macro that should be defined by the user prior to including
* the gdk.h header.
* The definition should be one of the predefined GDK version
* macros: %GDK_VERSION_3_0, %GDK_VERSION_3_2,...
*
* This macro defines the upper bound for the GDK API to use.
*
* If a function has been introduced in a newer version of GDK,
* it is possible to use this symbol to get compiler warnings when
* trying to use that function.
*
* Since: 3.4
*/
Obviously the exact method (define upper/lower/other limit) and
effects (warn, hide, error) differ between libraries but the overall
idea is there.
That said, I could have misunderstood something.

Hi Emil,

oh cool. I picked the two not best examples to look at. :-)

Post by Pekka Paalanen
We might need this kind of scheme for deprecating things in libwayland,
too.

Yes, I was hoping to get to that at some point.

Ack. I'll add a snippet of how the configure changes should look.

The name I chose is causing some confusion.
REQUIRE_LIBWESTON_API_VERSION sounds a lot better.

Now that you mentioned the semantics could be of upper or lower
limit, the name should imply the meaning. I only thought of using
it as both lower limit (as in pkg-config check) *and* upper limit
(do not declare API that was added after the given version or
remove API that was deprecated after the given version).

However, I also realized something more.

If you do like I suggested for configure.ac, you would have trouble
using pre-releases of libweston.

Pre-releases of, say 1.13.0, will be released as 1.12.9x. That
would be MINOR=12, so if you use the same numbers for both
pkg-config check and for the CPP macro for API, you cannot test the
13 API until it has been finally released.

So maybe those two need to be separate anyway?

Post by Emil Velikov
+
+
Libweston design goals
----------------------

Thanks,
pq

Emil Velikov

2016-07-07 16:11:35 UTC

Post by Pekka Paalanen
On Wed, 6 Jul 2016 13:57:48 +0100

Post by Pekka Paalanen
On Mon, 4 Jul 2016 15:23:51 +0100

Hi Emil,
I read that doc, and I fully agree with it now.

Strike "ensure" perhaps?

Yes, well spotted.

Neither have I found any reference/docs on the topic sadly.

On the libjpeg-turbo front, JPEG_LIB_VERSION is _optionally_ defined
and controls only the structs' layout.
On the GTK side I've made a typo - it should have been GDK.
Here is a snippet from /usr/include/gtk-3.0/gdk/gdkversionmacros.h
/**
*
* A macro that should be defined by the user prior to including
* the gdk.h header.
* The definition should be one of the predefined GDK version
* macros: %GDK_VERSION_3_0, %GDK_VERSION_3_2,...
*
* This macro defines the upper bound for the GDK API to use.
*
* If a function has been introduced in a newer version of GDK,
* it is possible to use this symbol to get compiler warnings when
* trying to use that function.
*
* Since: 3.4
*/
Obviously the exact method (define upper/lower/other limit) and
effects (warn, hide, error) differ between libraries but the overall
idea is there.
That said, I could have misunderstood something.

Hi Emil,
oh cool. I picked the two not best examples to look at. :-)

Post by Pekka Paalanen
We might need this kind of scheme for deprecating things in libwayland,
too.

Yes, I was hoping to get to that at some point.

Ack. I'll add a snippet of how the configure changes should look.

The name I chose is causing some confusion.
REQUIRE_LIBWESTON_API_VERSION sounds a lot better.

Ack. Considering I already know how it would/should be used, I'm a bit
short on unbiased name. Your earlier suggestion sounds great imho, but
if you have something else in mind please share it :-)

Post by Pekka Paalanen
However, I also realized something more.
If you do like I suggested for configure.ac, you would have trouble
using pre-releases of libweston.
Pre-releases of, say 1.13.0, will be released as 1.12.9x. That
would be MINOR=12, so if you use the same numbers for both
pkg-config check and for the CPP macro for API, you cannot test the
13 API until it has been finally released.
So maybe those two need to be separate anyway?

The example will cover this confusion, but the gist is that:
- No released version of software X should rely on development
version of libweston/libfoo.
- If there's a serious need to void the above, one should set the
REQUIRED_API to the number it would be in an official/final version.

Example:
libweston (devel. process):
- git tag 1.12.90
- Add API X, guarded behind version 0x010d version check (one could
keep the numbers decimal and/or other)
- other...

User:
- Bump required version to 1.12.90
- Use "-DREQUIRED_API_VERSION=0x010d"
Personally I'm leaning towards adding the define only in the
respective places that need the newer API, but having it in configure
(global scale) would be nice as well.

Thanks
Emil

Quentin Glidic

2016-07-07 18:08:40 UTC

[snip]
Now that you mentioned the semantics could be of upper or lower
limit, the name should imply the meaning. I only thought of using
it as both lower limit (as in pkg-config check) *and* upper limit
(do not declare API that was added after the given version or
remove API that was deprecated after the given version).

Ack. Considering I already know how it would/should be used, I'm a bit
short on unbiased name. Your earlier suggestion sounds great imho, but
if you have something else in mind please share it :-)

However, I also realized something more.
If you do like I suggested for configure.ac, you would have trouble
using pre-releases of libweston.
Pre-releases of, say 1.13.0, will be released as 1.12.9x. That
would be MINOR=12, so if you use the same numbers for both
pkg-config check and for the CPP macro for API, you cannot test the
13 API until it has been finally released.
So maybe those two need to be separate anyway?

- No released version of software X should rely on development
version of libweston/libfoo.
- If there's a serious need to void the above, one should set the
REQUIRED_API to the number it would be in an official/final version.
- git tag 1.12.90
- Add API X, guarded behind version 0x010d version check (one could
keep the numbers decimal and/or other)
- other...
- Bump required version to 1.12.90
- Use "-DREQUIRED_API_VERSION=0x010d"
Personally I'm leaning towards adding the define only in the
respective places that need the newer API, but having it in configure
(global scale) would be nice as well.

Regarding that, I’d go the GLib/GTK+ way completely.
That means each function has a
WESTON_AVAILABLE_IN(1, 13)

and *if* a project set
WESTON_VERSION_{MIN,MAX}_ALLOWED, that will make these functions
deprecated (not sure for the ones above the MAX).

The maint point is that I would rather have the new functions without
needing to update the define. Or most projects will use 0xffff as the
value. :-)

Cheers,

--
Quentin “Sardem FF7” Glidic

Emil Velikov

2016-07-08 10:52:10 UTC

Ack. Considering I already know how it would/should be used, I'm a bit
short on unbiased name. Your earlier suggestion sounds great imho, but
if you have something else in mind please share it :-)

IMHO forward compatibility is a more important topic than deprecation.
Thus I've focused on it in order to only make minimal changes. Your
suggestions sounds like the definition of 'complex' from IRC the other
day, but if you want the deprecation mechanism please go ahead.

Post by Quentin Glidic
The maint point is that I would rather have the new functions without
needing to update the define.

That completely defeats the purpose of the whole series.

Post by Quentin Glidic
Or most projects will use 0xffff as the value.

s/most/most of my/ perhaps ? ;-)

Bus seriously, as you noticed before - there is _nothing_ stopping
people from doing extremely stupid things.
If they do - it's up-to them to pick the pieces.

From my limited encounter so far on the wayland ML, it seems that
'compromise' it's conjugated too often :-(

-Emil

Quentin Glidic

2016-07-08 11:00:53 UTC

Ack. Considering I already know how it would/should be used, I'm a bit
short on unbiased name. Your earlier suggestion sounds great imho, but
if you have something else in mind please share it :-)

Post by Quentin Glidic
The maint point is that I would rather have the new functions without
needing to update the define.

That completely defeats the purpose of the whole series.

Post by Quentin Glidic
Or most projects will use 0xffff as the value.

s/most/most of my/ perhaps ? ;-)
Bus seriously, as you noticed before - there is _nothing_ stopping
people from doing extremely stupid things.
If they do - it's up-to them to pick the pieces.
From my limited encounter so far on the wayland ML, it seems that
'compromise' it's conjugated too often :-(

No, that series is still useful. *If* a project wants to be fully
compatible with version x.y, it will define WESTON_MAX_ALLOWED(x, y),
then newer symbols will be hidden.

If you believe most projects will do that, then fine, they want to be
“safe”, they do so, and they are happy.

Meanwhile, I and others who do not care about complete stability (and
more about features) can just use new symbols as they appear.

You said it, nothing will prevent all breakages, so why make it
difficult for the simple case? Simple case being “just use latest
version” (rolling releases distributions).

Deprecation is just the other half of the work, for people wanting to
avoid to-be-deleted stuff.

I would define MIN, not MAX, because I think (my) software should just
go forward.

--
Quentin “Sardem FF7” Glidic

Quentin Glidic

2016-07-08 11:17:05 UTC

On 7 July 2016 at 19:08, Quentin Glidic

Ack. Considering I already know how it would/should be used, I'm a bit
short on unbiased name. Your earlier suggestion sounds great imho, but
if you have something else in mind please share it :-)

Post by Quentin Glidic
The maint point is that I would rather have the new functions without
needing to update the define.

That completely defeats the purpose of the whole series.

Post by Quentin Glidic
Or most projects will use 0xffff as the value.

s/most/most of my/ perhaps ? ;-)
Bus seriously, as you noticed before - there is _nothing_ stopping
people from doing extremely stupid things.
If they do - it's up-to them to pick the pieces.
From my limited encounter so far on the wayland ML, it seems that
'compromise' it's conjugated too often :-(

No, that series is still useful. *If* a project wants to be fully
compatible with version x.y, it will define WESTON_MAX_ALLOWED(x, y),
then newer symbols will be hidden.
If you believe most projects will do that, then fine, they want to be
“safe”, they do so, and they are happy.
Meanwhile, I and others who do not care about complete stability (and
more about features) can just use new symbols as they appear.
You said it, nothing will prevent all breakages, so why make it
difficult for the simple case? Simple case being “just use latest
version” (rolling releases distributions).
Deprecation is just the other half of the work, for people wanting to
avoid to-be-deleted stuff.
I would define MIN, not MAX, because I think (my) software should just
go forward.

Neverming, just make sure one can define the needed stuff from
configure.ac. :-)

--
Quentin “Sardem FF7” Glidic

Emil Velikov

2016-07-08 11:41:06 UTC

Ack. Considering I already know how it would/should be used, I'm a bit
short on unbiased name. Your earlier suggestion sounds great imho, but
if you have something else in mind please share it :-)

Post by Quentin Glidic
The maint point is that I would rather have the new functions without
needing to update the define.

That completely defeats the purpose of the whole series.

Post by Quentin Glidic
Or most projects will use 0xffff as the value.

s/most/most of my/ perhaps ? ;-)
Bus seriously, as you noticed before - there is _nothing_ stopping
people from doing extremely stupid things.
If they do - it's up-to them to pick the pieces.
From my limited encounter so far on the wayland ML, it seems that
'compromise' it's conjugated too often :-(

The above sounds quite selfish - just because you don't care that
doesn't mean you have to enforce your preference onto everyone.
Also as you pointed out yourself - one can 'shoot themselves in the
foot' by using 0xffff as MAX if they really want to.

You said it, nothing will prevent all breakages, so why make it difficult
for the simple case? Simple case being “just use latest version” (rolling
releases distributions).

Not everyone is using rolling release distors. I would welcome you to
take a look how others are doing things and then you'll quickly
realise why I'm suggesting all this. One could say say/argue that
those distros should update (fix?) their tools, but even if they do
that's not going to happen overnight.

Ftr the "simple case" reference if one line for the whole project
isn't simple enough, I'm not sure what is.

Deprecation is just the other half of the work, for people wanting to avoid
to-be-deleted stuff.

The alternative doesn't sound that bad imho - just get things to
error, once the API is gone (and thus major is bumped)

I would define MIN, not MAX, because I think (my) software should just go
forward.

As said earlier, if you want the MIN/MAX feel free to send patches.

If you/others feel strongly against the patches in their form (with
Tiago and pq's comments addressed), so be it. I'll step away from all
the bikeshedding that this series has become.

-Emil

Pekka Paalanen

2016-07-09 15:32:48 UTC

On Thu, 7 Jul 2016 20:08:40 +0200

Ack. Considering I already know how it would/should be used, I'm a bit
short on unbiased name. Your earlier suggestion sounds great imho, but
if you have something else in mind please share it :-)

- No released version of software X should rely on development
version of libweston/libfoo.

Hi Emil,

an unreleased project must be able to depend on unreleased
libweston.

That's how the project communicates to its testers and developers
explicitly in configure.ac that it needs an unreleased version of
libweston. And we need projects to be able to do that, so that we
can have people test unreleased APIs of libweston.

This is what we currently do with 1.y.90 version. We never release
a 1.y.90, but projects can still check for and require it. It's
been working fine between wayland and weston so far, AFAIK.

Version 1.y.90 is not a proper version, it does not tell you which
revision of the code is the right one, but it does say "WIP" which
IMO is an important message.

If the user project then gets released with a dependency to a
library version 1.y.90, that's their fault. Hopefully they kept up
to date, so that release 1.y.91 satisfies the dependency.

Post by Emil Velikov
- If there's a serious need to void the above, one should set the
REQUIRED_API to the number it would be in an official/final version.

Indeed.

This is why my desire to derive both pkg-config version check and
the REQUIRED_API define from the single same source variable does
not work after all.

So, I think you're right, and we agree.

Post by Emil Velikov
- git tag 1.12.90
- Add API X, guarded behind version 0x010d version check (one could
keep the numbers decimal and/or other)
- other...
- Bump required version to 1.12.90
- Use "-DREQUIRED_API_VERSION=0x010d"
Personally I'm leaning towards adding the define only in the
respective places that need the newer API, but having it in configure
(global scale) would be nice as well.

Regarding that, Iâd go the GLib/GTK+ way completely.
That means each function has a
WESTON_AVAILABLE_IN(1, 13)
and *if* a project set
WESTON_VERSION_{MIN,MAX}_ALLOWED, that will make these functions
deprecated (not sure for the ones above the MAX).
The maint point is that I would rather have the new functions without
needing to update the define. Or most projects will use 0xffff as the
value. :-)

Hi Quentin,

I would not have new functions exposed without updating the define
value in user projects. Why? It gives the libweston users *both*
options.

I don't consider using 0xffff as a hack. I see it as an opt-in to
the scheme you are proposing, to get new functions exposed
automatically, which also puts you at risk of accidentally
depending on a newer version of libweston than before.

If we expose new functions regardless the define, then no-one can
choose to be safe from that accident, even if they wanted to.

Oh, reading your later replies, it seems you are only arguing over
which policy should be the default. I'd say neither. Make the build
just error out if the user defines neither way. The definition will
be just one line in the user project's config.h anyway.

Thanks,
pq

Emil Velikov

2016-07-11 14:58:57 UTC

Post by Pekka Paalanen
On Thu, 7 Jul 2016 20:08:40 +0200

Ack. Considering I already know how it would/should be used, I'm a bit
short on unbiased name. Your earlier suggestion sounds great imho, but
if you have something else in mind please share it :-)

- No released version of software X should rely on development
version of libweston/libfoo.

Hi Emil,
an unreleased project must be able to depend on unreleased
libweston.
That's how the project communicates to its testers and developers
explicitly in configure.ac that it needs an unreleased version of
libweston. And we need projects to be able to do that, so that we
can have people test unreleased APIs of libweston.
This is what we currently do with 1.y.90 version. We never release
a 1.y.90, but projects can still check for and require it. It's
been working fine between wayland and weston so far, AFAIK.
Version 1.y.90 is not a proper version, it does not tell you which
revision of the code is the right one, but it does say "WIP" which
IMO is an important message.
If the user project then gets released with a dependency to a
library version 1.y.90, that's their fault. Hopefully they kept up
to date, so that release 1.y.91 satisfies the dependency.

Fully agree.

Speaking of which... I don't think we got the wayland patch for mesa
in. /me double-checks.

Post by Emil Velikov
- If there's a serious need to void the above, one should set the
REQUIRED_API to the number it would be in an official/final version.

Indeed.
This is why my desire to derive both pkg-config version check and
the REQUIRED_API define from the single same source variable does
not work after all.
So, I think you're right, and we agree.

Regarding that, I’d go the GLib/GTK+ way completely.
That means each function has a
WESTON_AVAILABLE_IN(1, 13)
and *if* a project set
WESTON_VERSION_{MIN,MAX}_ALLOWED, that will make these functions
deprecated (not sure for the ones above the MAX).
The maint point is that I would rather have the new functions without
needing to update the define. Or most projects will use 0xffff as the
value. :-)

Hi Quentin,
I would not have new functions exposed without updating the define
value in user projects. Why? It gives the libweston users *both*
options.
I don't consider using 0xffff as a hack. I see it as an opt-in to
the scheme you are proposing, to get new functions exposed
automatically, which also puts you at risk of accidentally
depending on a newer version of libweston than before.
If we expose new functions regardless the define, then no-one can
choose to be safe from that accident, even if they wanted to.
Oh, reading your later replies, it seems you are only arguing over
which policy should be the default. I'd say neither. Make the build
just error out if the user defines neither way. The definition will
be just one line in the user project's config.h anyway.

You're right - calling 0xffff names isn't the most mature thing, sorry
about that.

And yes, the goal here is/was to error out by default in order to
avoid accidental damage. Anyone not interested in this safety switch
can add one line to override it.

Thanks for guidance in all this.
Emil

Thiago Macieira

2016-07-07 17:55:08 UTC

Post by Emil Velikov
+Similar approach is used by ATK, QT and KDE programs/libraries,

Qt, with a lowercase t.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

Emil Velikov

2016-07-04 14:23:53 UTC

From: Emil Velikov <***@collabora.com>

When managing headers there's normally two ways to handle them
- with or without the subfolder.

Opting for the latter case here, since it will provide direct feedback,
whether one is using libweston-0 or any other version.

Which in turn should deter (help prevent) issues like building/linking
against multiple versions of libweston.

Signed-off-by: Emil Velikov <***@collabora.com>
---
libweston/libweston.pc.in | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libweston/libweston.pc.in b/libweston/libweston.pc.in
index 24fe813..bb95af9 100644
--- a/libweston/libweston.pc.in
+++ b/libweston/libweston.pc.in
@@ -2,11 +2,10 @@ prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@
-pkgincludedir=${includedir}/libweston-@LIBWESTON_ABI_VERSION@

Name: libweston API
Description: Header files for libweston compositors development
Version: @WESTON_VERSION@
Requires.private: wayland-server pixman-1 xkbcommon
-Cflags: -I${pkgincludedir}
+Cflags: -I${includedir}
Libs: -L${libdir} -lweston-@LIBWESTON_ABI_VERSION@

--
2.8.2

Quentin Glidic

2016-07-04 14:32:20 UTC

Post by Emil Velikov
When managing headers there's normally two ways to handle them
- with or without the subfolder.
Opting for the latter case here, since it will provide direct feedback,
whether one is using libweston-0 or any other version.
Which in turn should deter (help prevent) issues like building/linking
against multiple versions of libweston.

I really prefer not to do that. It means supporting multiple versions of
libweston will lead to a really big #ifdef dance at the top of the file
to include every single version you might support, instead of a just a
few #ifdef around specific new/old functions you use.

NAK for me.

Cheers,

Post by Emil Velikov
---
libweston/libweston.pc.in | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libweston/libweston.pc.in b/libweston/libweston.pc.in
index 24fe813..bb95af9 100644
--- a/libweston/libweston.pc.in
+++ b/libweston/libweston.pc.in
@@ -2,11 +2,10 @@ prefix=@prefix@
Name: libweston API
Description: Header files for libweston compositors development
Requires.private: wayland-server pixman-1 xkbcommon
-Cflags: -I${pkgincludedir}
+Cflags: -I${includedir}

--
Quentin “Sardem FF7” Glidic

Emil Velikov

2016-07-04 15:02:23 UTC

I really prefer not to do that. It means supporting multiple versions of
libweston will lead to a really big #ifdef dance at the top of the file to
include every single version you might support, instead of a just a few
#ifdef around specific new/old functions you use.

Yes, I agree with you - adding ifdef spaghetti is ugly. Then again, if
one wants to support multiple versions they will need a bunch of them
either way.

Keeping things explicit will give (and/or save) you and others a fair
bit of time when it goes wrong/nasty. Here is an (somewhat silly, or
you might say sad) example I've seen in the open-source Tizen world...
or was it Android:

Dev. lacks exact knowledge when function A (libfoo1) and B (libfoo2)
are introduced. Thus he/she adds both versions of libfoo in the
configure pkg-config checks. At which point, you will have symbol
collisions, seemingly random corruption and/or crashes.

Cheers,
Emil

Pekka Paalanen

2016-07-07 09:20:36 UTC

On Mon, 4 Jul 2016 16:02:23 +0100

I really prefer not to do that. It means supporting multiple versions of
libweston will lead to a really big #ifdef dance at the top of the file to
include every single version you might support, instead of a just a few
#ifdef around specific new/old functions you use.

Yes, I agree with you - adding ifdef spaghetti is ugly. Then again, if
one wants to support multiple versions they will need a bunch of them
either way.
Keeping things explicit will give (and/or save) you and others a fair
bit of time when it goes wrong/nasty. Here is an (somewhat silly, or
you might say sad) example I've seen in the open-source Tizen world...
Dev. lacks exact knowledge when function A (libfoo1) and B (libfoo2)
are introduced. Thus he/she adds both versions of libfoo in the
configure pkg-config checks. At which point, you will have symbol
collisions, seemingly random corruption and/or crashes.

Hi Emil,

I'm not sure I get that example.

I read the long IRC discussion between the two of you the other
day, and I have to say I'm on Quentin's side on this, solely because
switching from one libweston version to the next will cause lots of
"unnecessary" changes if you need to fix the #include directives
everywhere. I also do not think doing that mechanical excercise
will make anyone think about the actual ABI changes.

If we want to make sure users actually notice libweston ABI
changes, we need to make those as build-breaking API changes too.
That's the only feasible thing I can think of, unless we had someone
writing a checklist of all the ABI changes - a fat chance - and
hoping that downstream devs actually go through it.

Therefore a NAK from me too.

Thanks,
pq

Emil Velikov

2016-07-07 16:28:47 UTC

Post by Pekka Paalanen
On Mon, 4 Jul 2016 16:02:23 +0100

I really prefer not to do that. It means supporting multiple versions of
libweston will lead to a really big #ifdef dance at the top of the file to
include every single version you might support, instead of a just a few
#ifdef around specific new/old functions you use.

Yes, I agree with you - adding ifdef spaghetti is ugly. Then again, if
one wants to support multiple versions they will need a bunch of them
either way.
Keeping things explicit will give (and/or save) you and others a fair
bit of time when it goes wrong/nasty. Here is an (somewhat silly, or
you might say sad) example I've seen in the open-source Tizen world...
Dev. lacks exact knowledge when function A (libfoo1) and B (libfoo2)
are introduced. Thus he/she adds both versions of libfoo in the
configure pkg-config checks. At which point, you will have symbol
collisions, seemingly random corruption and/or crashes.

+1 for well use of quotation marks :-)

Post by Pekka Paalanen
changes if you need to fix the #include directives
everywhere. I also do not think doing that mechanical excercise
will make anyone think about the actual ABI changes.

"Anyone" is an overstatement. I might be a minority, but I would make
the effort of checking the API's (I use) in such cases. The whole
example and logic steers on the idea that the greater the effort
required by the user the larger likelihood that they will stop and
think for a second "wait there might be a reason behind all this
annoyance". As said, I'm likely a minority here.

Post by Pekka Paalanen
If we want to make sure users actually notice libweston ABI
changes, we need to make those as build-breaking API changes too.
That's the only feasible thing I can think of, unless we had someone
writing a checklist of all the ABI changes - a fat chance - and
hoping that downstream devs actually go through it.

Yes, it's impossible to make thing completely bullet proof or even get
some (most?) users to read through the changelog. That is unless
things blow up in their face :-)

Post by Pekka Paalanen
Therefore a NAK from me too.

As you guys wish. In that case can we drop the pkgincludedir variable
? Most packages don't bother with it (on my local setup only 7 out of
740 do)

Thanks
Emil

Quentin Glidic

2016-07-07 18:18:19 UTC

[snip]
Therefore a NAK from me too.

As you guys wish. In that case can we drop the pkgincludedir variable
? Most packages don't bother with it (on my local setup only 7 out of
740 do)

Is there a strong reason to remove it? Right now I would see it as a
noise commit with no real value.

Cheers,

--
Quentin “Sardem FF7” Glidic

Emil Velikov

2016-07-08 10:31:42 UTC

[snip]
Therefore a NAK from me too.

As you guys wish. In that case can we drop the pkgincludedir variable
? Most packages don't bother with it (on my local setup only 7 out of
740 do)

Is there a strong reason to remove it? Right now I would see it as a noise
commit with no real value.

If 100 to 1 ratio isn't enough, I don't think anything is. Then again,
I'm wondering if the topic hasn't turned into a perfect bikeshedding
example ?

-Emil

Pekka Paalanen

2016-07-09 15:40:09 UTC

On Fri, 8 Jul 2016 11:31:42 +0100

[snip]
Therefore a NAK from me too.

As you guys wish. In that case can we drop the pkgincludedir variable
? Most packages don't bother with it (on my local setup only 7 out of
740 do)

Is there a strong reason to remove it? Right now I would see it as a noise
commit with no real value.

If 100 to 1 ratio isn't enough, I don't think anything is. Then again,
I'm wondering if the topic hasn't turned into a perfect bikeshedding
example ?

Hi Emil,

if you really care about that one variable so much to write a patch
for it, I shall merge it. I believe nothing should be asking
the .pc about a pkgincludedir specifically, right?

Thanks,
pq

Emil Velikov

2016-07-04 14:23:54 UTC

From: Emil Velikov <***@collabora.com>

Signed-off-by: Emil Velikov <***@collabora.com>
---
configure.ac | 1 +
libweston/libweston.pc.in | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index be40f10..46b61ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+AC_SUBST([LIBWESTON_VERSION], [libweston_major_version.libweston_minor_version.libweston_patch_version])
m4_define([lt_current], [libweston_minor_version])
m4_define([lt_revision], [libweston_patch_version])
m4_define([lt_age], [libweston_minor_version])
diff --git a/libweston/libweston.pc.in b/libweston/libweston.pc.in
index bb95af9..41ea8d7 100644
--- a/libweston/libweston.pc.in
+++ b/libweston/libweston.pc.in
@@ -5,7 +5,7 @@ includedir=@includedir@

Name: libweston API
Description: Header files for libweston compositors development
-Version: @WESTON_VERSION@
+Version: @LIBWESTON_VERSION@
Requires.private: wayland-server pixman-1 xkbcommon
Cflags: -I${includedir}
Libs: -L${libdir} -lweston-@LIBWESTON_ABI_VERSION@

--
2.8.2

Quentin Glidic

2016-07-04 14:35:26 UTC

Post by Emil Velikov
---
configure.ac | 1 +
libweston/libweston.pc.in | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index be40f10..46b61ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+AC_SUBST([LIBWESTON_VERSION], [libweston_major_version.libweston_minor_version.libweston_patch_version])

That makes packaging a pain. Although the whole libweston (supposedly
parallel-installable) is already a pain.

When you have a project with a dep on libweston, you’ll have to dig the
weston version because the tarball is versioned as weston.

I would only do that once (and if) we split libweston and weston to
different repositories.

Post by Emil Velikov
m4_define([lt_current], [libweston_minor_version])
m4_define([lt_revision], [libweston_patch_version])
m4_define([lt_age], [libweston_minor_version])
diff --git a/libweston/libweston.pc.in b/libweston/libweston.pc.in
index bb95af9..41ea8d7 100644
--- a/libweston/libweston.pc.in
+++ b/libweston/libweston.pc.in
@@ -5,7 +5,7 @@ includedir=@includedir@
Name: libweston API
Description: Header files for libweston compositors development
Requires.private: wayland-server pixman-1 xkbcommon
Cflags: -I${includedir}

--
Quentin “Sardem FF7” Glidic

Emil Velikov

2016-07-04 15:25:54 UTC

Post by Emil Velikov
---
configure.ac | 1 +
libweston/libweston.pc.in | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index be40f10..46b61ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+AC_SUBST([LIBWESTON_VERSION],
[libweston_major_version.libweston_minor_version.libweston_patch_version])

That makes packaging a pain. Although the whole libweston (supposedly
parallel-installable) is already a pain.
When you have a project with a dep on libweston, you’ll have to dig the
weston version because the tarball is versioned as weston.
I would only do that once (and if) we split libweston and weston to
different repositories.

Yes splitting libweston into separate repo makes sense. Yet I failed
to see where the actual pain is - there is a minor annoyance, and devs
and/or distro maintainers have learned to deal with a lot nastier
things through the years.

If anything, having libweston-2 provided by (a future)
libweston-1.12.0 tarball/package would make things even more
confusing/annoying. That is unless one is planning to say "f**k it,
let's decrease the version" upon the split. With the later upsetting a
lot of people.

-Emil

Pekka Paalanen

2016-07-07 09:46:50 UTC

On Mon, 4 Jul 2016 16:25:54 +0100

Post by Emil Velikov
---
configure.ac | 1 +
libweston/libweston.pc.in | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index be40f10..46b61ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+AC_SUBST([LIBWESTON_VERSION],
[libweston_major_version.libweston_minor_version.libweston_patch_version])

That makes packaging a pain. Although the whole libweston (supposedly
parallel-installable) is already a pain.
When you have a project with a dep on libweston, youâll have to dig the
weston version because the tarball is versioned as weston.
I would only do that once (and if) we split libweston and weston to
different repositories.

Yes splitting libweston into separate repo makes sense. Yet I failed
to see where the actual pain is - there is a minor annoyance, and devs
and/or distro maintainers have learned to deal with a lot nastier
things through the years.
If anything, having libweston-2 provided by (a future)
libweston-1.12.0 tarball/package would make things even more
confusing/annoying. That is unless one is planning to say "f**k it,
let's decrease the version" upon the split. With the later upsetting a
lot of people.

Hi guys,

my 2c again:

I don't think splitting weston and libweston to separate
repositories can happen any time soon, because of the test suite
that is specific to weston. I do not want to duplicate the test
suite, and I do not want 'make check' in libweston to be useless,
so we need to keep them together for now.

I also think that we don't need separate versioning for weston and
libweston. Let's just use the same for both, now that the plans are
clarifying.

Yes, it does mean the following:

- weston version number will start to deviate from wayland, even
when both are still released at the same time

- weston version number will be the same as libweston it uses

- MAJOR will start running like hell, we'll probably get to weston
27.0.0 before it slows down, or whatever

But, that's all fine with me, considering the confusion any other
scheme would raise.

I suppose (lib)weston release 1.12.0 would be last MAJOR=1 release
of weston, installing libweston-1.so, and then we'd just bump to
weston 2.0.0 on the next final release.

How's that?

Hmm... but again, if we use MAJOR like that, then during the
development of 2.0.0 we would be still installing libweston-1.so
because our version in git master is 1.12.90 until the first
pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
How to solve that? Or is it not a problem?

The thing is, libweston 1.12.90 will be completely incompatible
with libweston 1.12.0.

Should .9x be a special case somehow, installed as
libweston-1-90.so or such?

This is starting to sound very much like what I read about GTK
trying a new versioning scheme...

Thanks,
pq

Emil Velikov

2016-07-07 16:45:24 UTC

Post by Pekka Paalanen
On Mon, 4 Jul 2016 16:25:54 +0100

Post by Emil Velikov
---
configure.ac | 1 +
libweston/libweston.pc.in | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index be40f10..46b61ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+AC_SUBST([LIBWESTON_VERSION],
[libweston_major_version.libweston_minor_version.libweston_patch_version])

That makes packaging a pain. Although the whole libweston (supposedly
parallel-installable) is already a pain.
When you have a project with a dep on libweston, you’ll have to dig the
weston version because the tarball is versioned as weston.
I would only do that once (and if) we split libweston and weston to
different repositories.

Yes splitting libweston into separate repo makes sense. Yet I failed
to see where the actual pain is - there is a minor annoyance, and devs
and/or distro maintainers have learned to deal with a lot nastier
things through the years.
If anything, having libweston-2 provided by (a future)
libweston-1.12.0 tarball/package would make things even more
confusing/annoying. That is unless one is planning to say "f**k it,
let's decrease the version" upon the split. With the later upsetting a
lot of people.

Hi guys,
I don't think splitting weston and libweston to separate
repositories can happen any time soon, because of the test suite
that is specific to weston. I do not want to duplicate the test
suite, and I do not want 'make check' in libweston to be useless,
so we need to keep them together for now.

If there were more developers, one could also move the tests into a
separate repo. Although that (plus libweston) would require extensive
audit of the private and public headers since atm, things are quite
fragile (one might even call them busted).

Post by Pekka Paalanen
I also think that we don't need separate versioning for weston and
libweston. Let's just use the same for both, now that the plans are
clarifying.
- weston version number will start to deviate from wayland, even
when both are still released at the same time

Don't think this is a serious problem, I've even recall people being
confused why they are still in sync.

Post by Pekka Paalanen
- weston version number will be the same as libweston it uses
- MAJOR will start running like hell, we'll probably get to weston
27.0.0 before it slows down, or whatever
But, that's all fine with me, considering the confusion any other
scheme would raise.
I suppose (lib)weston release 1.12.0 would be last MAJOR=1 release
of weston, installing libweston-1.so, and then we'd just bump to
weston 2.0.0 on the next final release.
How's that?

This sounds like a good plan to me, fwiw.

Post by Pekka Paalanen
Hmm... but again, if we use MAJOR like that, then during the
development of 2.0.0 we would be still installing libweston-1.so
because our version in git master is 1.12.90 until the first
pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
How to solve that? Or is it not a problem?
The thing is, libweston 1.12.90 will be completely incompatible
with libweston 1.12.0.
Should .9x be a special case somehow, installed as
libweston-1-90.so or such?

As mentioned elsewhere - one should not rely on development version of
project foo having stable interface(s). That said, making sure that
things aren't too crazy for people that do want to test them is a must
imho.
Nobody (?) wants to deter their testers away.

Post by Pekka Paalanen
This is starting to sound very much like what I read about GTK
trying a new versioning scheme...

That might be a good idea. Are you talking about [1] [2] ?
Alternatively do you have a link/keywords on the topic ?

"Versionning - there's always more to it than one expects" ;-)

Thanks
Emil

[1] https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
[2] https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0-is-not-gtk-5/

Pekka Paalanen

2016-07-09 16:26:00 UTC

On Thu, 7 Jul 2016 17:45:24 +0100

Post by Pekka Paalanen
On Mon, 4 Jul 2016 16:25:54 +0100

Post by Emil Velikov
---
configure.ac | 1 +
libweston/libweston.pc.in | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index be40f10..46b61ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+AC_SUBST([LIBWESTON_VERSION],
[libweston_major_version.libweston_minor_version.libweston_patch_version])

Yes splitting libweston into separate repo makes sense. Yet I failed
to see where the actual pain is - there is a minor annoyance, and devs
and/or distro maintainers have learned to deal with a lot nastier
things through the years.
If anything, having libweston-2 provided by (a future)
libweston-1.12.0 tarball/package would make things even more
confusing/annoying. That is unless one is planning to say "f**k it,
let's decrease the version" upon the split. With the later upsetting a
lot of people.

More developers or not, I am not so optimistic that it would work.

The tests have code intimately tied to internal APIs of both weston
and libweston. That alone is reason enough. It may not even be
possible to get rid of that, realistically.

To be able to run libweston, we'd essentially need a copy of weston
anyway, for initializing it.

Don't think this is a serious problem, I've even recall people being
confused why they are still in sync.

Heh, cool.

This sounds like a good plan to me, fwiw.

Alright.

This issue is being discussed in my reply to Jan, so I'd prefer to
continue in that part of the thread.

Post by Pekka Paalanen
This is starting to sound very much like what I read about GTK
trying a new versioning scheme...

That might be a good idea. Are you talking about [1] [2] ?
Alternatively do you have a link/keywords on the topic ?
"Versionning - there's always more to it than one expects" ;-)
Thanks
Emil
[1] https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
[2] https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0-is-not-gtk-5/

Reference [1] is what I had in mind. However, I'd probably not have
a "random" MINOR version declared as the final API/ABI of the
MAJOR. As I don't mind MAJOR running to high numbers, I'd prefer to
have MAJOR bump signify API/ABI breaks like people would
usually expect. Right?

I just read [2] for the first time. The difference is IMO that we
don't have a schedule or a plan (yet) like GTK has for cutting
stable releases. Getting Weston/libweston forward is already painful
enough that I don't want to care about breaking things, let's just
bump MAJOR every time. We also don't do the odd/even versioning,
and I don't think we have a user like GNOME is for GTK in that
you'd need sort-of-stable-but-not-really releases - breaking
backward compat with each release is what we will do for a long
time.

Thanks,
pq

Emil Velikov

2016-07-11 15:14:33 UTC

Post by Pekka Paalanen
On Thu, 7 Jul 2016 17:45:24 +0100

Post by Pekka Paalanen
On Mon, 4 Jul 2016 16:25:54 +0100

Post by Emil Velikov
---
configure.ac | 1 +
libweston/libweston.pc.in | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index be40f10..46b61ae 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,6 +21,7 @@ AC_SUBST([WESTON_VERSION_MINOR], [weston_minor_version])
AC_SUBST([WESTON_VERSION_MICRO], [weston_micro_version])
AC_SUBST([WESTON_VERSION], [weston_version])
AC_SUBST([LIBWESTON_MAJOR], [libweston_major_version])
+AC_SUBST([LIBWESTON_VERSION],
[libweston_major_version.libweston_minor_version.libweston_patch_version])

That makes packaging a pain. Although the whole libweston (supposedly
parallel-installable) is already a pain.
When you have a project with a dep on libweston, you’ll have to dig the
weston version because the tarball is versioned as weston.
I would only do that once (and if) we split libweston and weston to
different repositories.

Yes splitting libweston into separate repo makes sense. Yet I failed
to see where the actual pain is - there is a minor annoyance, and devs
and/or distro maintainers have learned to deal with a lot nastier
things through the years.
If anything, having libweston-2 provided by (a future)
libweston-1.12.0 tarball/package would make things even more
confusing/annoying. That is unless one is planning to say "f**k it,
let's decrease the version" upon the split. With the later upsetting a
lot of people.

More developers or not, I am not so optimistic that it would work.
The tests have code intimately tied to internal APIs of both weston
and libweston. That alone is reason enough. It may not even be
possible to get rid of that, realistically.
To be able to run libweston, we'd essentially need a copy of weston
anyway, for initializing it.

Had no idea about those. I'd imagine that one could handle those with
git submodules, although that might be a bit fragile and it'll require
a ton more development effort that there is atm.

Just food for though, than a serious suggestion.

Don't think this is a serious problem, I've even recall people being
confused why they are still in sync.

Heh, cool.

This sounds like a good plan to me, fwiw.

Alright.

This issue is being discussed in my reply to Jan, so I'd prefer to
continue in that part of the thread.

Post by Pekka Paalanen
This is starting to sound very much like what I read about GTK
trying a new versioning scheme...

That might be a good idea. Are you talking about [1] [2] ?
Alternatively do you have a link/keywords on the topic ?
"Versionning - there's always more to it than one expects" ;-)
Thanks
Emil
[1] https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/
[2] https://blogs.gnome.org/desrt/2016/06/14/gtk-5-0-is-not-gtk-5/

Precisely. Running into high MAJOR shouldn't be an issue, plus there
aren't as many users of libweston (as they are for GTK), that the API
will require the long period of definition (to mature).

Post by Pekka Paalanen
I just read [2] for the first time. The difference is IMO that we
don't have a schedule or a plan (yet) like GTK has for cutting
stable releases. Getting Weston/libweston forward is already painful
enough that I don't want to care about breaking things, let's just
bump MAJOR every time. We also don't do the odd/even versioning,
and I don't think we have a user like GNOME is for GTK in that
you'd need sort-of-stable-but-not-really releases - breaking
backward compat with each release is what we will do for a long
time.

Ack, makes perfect sense, imho.

-Emil

Jan Engelhardt

2016-07-09 03:19:26 UTC

Post by Emil Velikov
+AC_SUBST([LIBWESTON_VERSION],
[libweston_major_version.libweston_minor_version.libweston_patch_version])

That makes packaging a pain. Although the whole libweston (supposedly
parallel-installable) is already a pain.

First, what kind of parallel installability is sought?

* just runtime
* parallel development environment (like what e.g. libabw,
librevenge.. do)

Few projects ever go to the length of making their /usr/include
headers or .pc files coinstallable by including some version number in
it.

Post by Pekka Paalanen
- MAJOR will start running like hell, we'll probably get to weston
27.0.0 before it slows down, or whatever

- do you care about release numbering? (Projects with equally high
numbers don't anymore; like Chrome, Firefox, systemd)
- if just parallel runtime is the goal: done deal, just bump
the SO/ABI version (libfoo.so.2, .so.3), no one cares about
how high they go
- I imagine that no one cares about the SONAME either, so you could
try banishing the SO version into the basename and getting away with
it. Might cause $confusion.
(libfoo 1.12: libfoo-2.so.0; libfoo 2.0 libfoo-4.so.0)

Some projects make the bump at the start of the development cycle,
some do it just before the tarball release, and some do it together
with the first incompatible change (i.e. midway).

To be really foolproof, every _commit_ that changes things in an
incompatible way would need a bump, but that is too much hassle for
most, so they just do it between tarball releases in one of the three
just-mentioned ways.

Post by Pekka Paalanen
The thing is, libweston 1.12.90 will be completely incompatible
with libweston 1.12.0.
Should .9x be a special case somehow, installed as
libweston-1-90.so or such?

Since 1.12.90 is probably not incompatible to 1.13.0,
they both would install whatever 1.13.0 would have used.

Pekka Paalanen

2016-07-09 16:24:25 UTC

On Sat, 9 Jul 2016 05:19:26 +0200 (CEST)

Post by Emil Velikov
+AC_SUBST([LIBWESTON_VERSION],
[libweston_major_version.libweston_minor_version.libweston_patch_version])

That makes packaging a pain. Although the whole libweston (supposedly
parallel-installable) is already a pain.

First, what kind of parallel installability is sought?
* just runtime
* parallel development environment (like what e.g. libabw,
librevenge.. do)

Hi,

everything that is about libweston including development enviroment
has been my idea.

Post by Jan Engelhardt
Few projects ever go to the length of making their /usr/include
headers or .pc files coinstallable by including some version number in
it.

Is there any particular downside of going all the way?

Post by Pekka Paalanen
- MAJOR will start running like hell, we'll probably get to weston
27.0.0 before it slows down, or whatever

- do you care about release numbering? (Projects with equally high
numbers don't anymore; like Chrome, Firefox, systemd)

I don't mind (anymore).

Post by Jan Engelhardt
- if just parallel runtime is the goal: done deal, just bump
the SO/ABI version (libfoo.so.2, .so.3), no one cares about
how high they go

We also have plugins and other stuff, to be scoped by installation
directory.

Wouldn't that cause installations to have a libfoo.so symlink
without a version number? That we do not want, a too high risk of
pointing to a wrong version.

Post by Jan Engelhardt
- I imagine that no one cares about the SONAME either, so you could
try banishing the SO version into the basename and getting away with
it. Might cause $confusion.
(libfoo 1.12: libfoo-2.so.0; libfoo 2.0 libfoo-4.so.0)

I'd like to avoid such confusion if possible, and use simply (the
to be when released) MAJOR in the SONAME.

Some projects make the bump at the start of the development cycle,
some do it just before the tarball release, and some do it together
with the first incompatible change (i.e. midway).
To be really foolproof, every _commit_ that changes things in an
incompatible way would need a bump, but that is too much hassle for
most, so they just do it between tarball releases in one of the three
just-mentioned ways.

We have been bumping the project version to 1.y.90 right after the
release of 1.y.0, at the start of the development cycle. This way
unreleased projects can depend on our unreleased project.

Post by Pekka Paalanen
The thing is, libweston 1.12.90 will be completely incompatible
with libweston 1.12.0.
Should .9x be a special case somehow, installed as
libweston-1-90.so or such?

Since 1.12.90 is probably not incompatible to 1.13.0,
they both would install whatever 1.13.0 would have used.

Indeed, yes.

The point is, we need to define the libweston MAJOR to be used in
installations separately from the project MAJOR, even if they will
always match with releases, because they won't match during
development.

That's probably the simplest solution for starters. We could add
configure.ac automation to use MAJOR+1 in the SONAME when project
MICRO >= 90, too. Or maybe that will be MINOR >= 90 once we get to
the habit of bumping MAJOR.

Thanks,
pq

Jan Engelhardt

2016-07-10 10:11:39 UTC

Post by Jan Engelhardt
First, what kind of parallel installability is sought?
* just runtime
* parallel development environment (like what e.g. libabw,
librevenge.. do)

everything that is about libweston including development enviroment
has been my idea.

Post by Jan Engelhardt
Few projects ever go to the length of making their /usr/include
headers or .pc files coinstallable by including some version number in
it.

Is there any particular downside of going all the way?

For example, if a program supports being built for gtk2 and gtk3,
it can't simply do
PKG_CHECK_MODULES([gtk], [gtk >= 2])
because the developers chose to stick the version in the basename :-(
Which means that someone has to do
PKG_CHECK_EXISTS([gtk-2.0], [PKG_CHECK_MODULES([gtk], [gtk-2.0])], [
PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
...repeat the fun...
])]

Now with gtk it was not so much a problem (yet!) because there
are only two different basenames in 15-or-so years.
But if weston wants to go to 27 "soon" (...)

Post by Pekka Paalanen
- MAJOR will start running like hell, we'll probably get to weston
27.0.0 before it slows down, or whatever

- if just parallel runtime is the goal: done deal, just bump
the SO/ABI version (libfoo.so.2, .so.3), no one cares about
how high they go

We also have plugins and other stuff, to be scoped by installation
directory.
Wouldn't that cause installations to have a libfoo.so symlink
without a version number? That we do not want, a too high risk of
pointing to a wrong version.

The .so symlink is really only for /usr/bin/ld. It does not
play a role for ld.so (ld-linux.so.*) and therefore won't
interfere with plugins living in versioned directories.
(Cf. libmirage from cdemu)

Post by Pekka Paalanen
The point is, we need to define the libweston MAJOR to be used in
installations separately from the project MAJOR, even if they will
always match with releases, because they won't match during
development.
That's probably the simplest solution for starters. We could add
configure.ac automation to use MAJOR+1 in the SONAME when project
MICRO >= 90, too. Or maybe that will be MINOR >= 90 once we get to
the habit of bumping MAJOR.

Or you can just have two lines in configure.ac next to each other
which will scream at you "update me in lockstep" everytime you look
at them because you modify one of them.

AC_INIT([libweston], [1.12.0])
libweston_SONUM=3
->
AC_INIT([libweston], [1.12.90])
libweston_SONUM=27

Emil Velikov

2016-07-10 10:46:45 UTC

Post by Jan Engelhardt
First, what kind of parallel installability is sought?
* just runtime
* parallel development environment (like what e.g. libabw,
librevenge.. do)

everything that is about libweston including development enviroment
has been my idea.

Post by Jan Engelhardt
Few projects ever go to the length of making their /usr/include
headers or .pc files coinstallable by including some version number in
it.

Is there any particular downside of going all the way?

Yes, it's one line of fun for each version that you want to be
compatible with. It's not ideal, but it's a price to pay, for keeping
things compatible/sane.

Post by Jan Engelhardt
Now with gtk it was not so much a problem (yet!) because there
are only two different basenames in 15-or-so years.
But if weston wants to go to 27 "soon" (...)

Post by Pekka Paalanen
- MAJOR will start running like hell, we'll probably get to weston
27.0.0 before it slows down, or whatever

- if just parallel runtime is the goal: done deal, just bump
the SO/ABI version (libfoo.so.2, .so.3), no one cares about
how high they go

We also have plugins and other stuff, to be scoped by installation
directory.
Wouldn't that cause installations to have a libfoo.so symlink
without a version number? That we do not want, a too high risk of
pointing to a wrong version.

True, it won't interfere with plugins living in versionned
(sub)directories, since those are already linked against the correct
binary. The (main?) problem that Pekka is pointing out is that we
don't know which version we'll link against. Why you might ask - the
libfoo.so symlink may point to libfoo.so.2, libfoo.so.3 or
libfoo.so.X. Since we don't have (imho for a very good reason) control
which version of the said library we want to link against, we rely on
libfoo.so being correct.

I get the feeling that you have not read the following
http://ometer.com/parallel.html. I would strongly recommend giving it
a look.

Or you can just have two lines in configure.ac next to each other
which will scream at you "update me in lockstep" everytime you look
at them because you modify one of them.
AC_INIT([libweston], [1.12.0])
libweston_SONUM=3
->
AC_INIT([libweston], [1.12.90])
libweston_SONUM=27

This could also work, but Pekka's idea sounds more robust and simpler
in the long run. Add the logic once and don't bother checking/keeping
things in sync ;-)

Just my 2c, as they say.
Emil

Jan Engelhardt

2016-07-10 12:23:36 UTC

Post by Jan Engelhardt
PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
...repeat the fun...
])]

Yes, it's one line of fun for each version that you want to be
compatible with. It's not ideal, but it's a price to pay, for keeping
things compatible/sane.

Without pkgconfig supporting some new alias tag (hint, hint) to cover
such a case, I predict that whoever uses libfoo-LotsANumbersHere
limits themselves to 3 or maybe 4 PKG_CHECK_MODULES calls, because it
is looking real silly.

Post by Jan Engelhardt
The .so symlink is really only for /usr/bin/ld. It does not
play a role for ld.so (ld-linux.so.*) and therefore won't
interfere with plugins living in versioned directories.
(Cf. libmirage from cdemu)

The (main?) problem [...] is that we [...] rely on libfoo.so being
correct.
I get the feeling that you have not read the following
http://ometer.com/parallel.html. I would strongly recommend giving it
a look.

I read it now, and I do not buy it - at least not for 2016 standards.
According to the page, it was written in 2002, and I can confirm that
the situation was much worse then it is now. I can practically refute
all his points from the "Some more issues:" section, but for brevity,
I spare you the details for now.

Post by Jan Engelhardt
Or you can just have two lines in configure.ac next to each other
which will scream at you "update me in lockstep" everytime you look
at them because you modify one of them.
AC_INIT([libweston], [1.12.0])
libweston_SONUM=3
->
AC_INIT([libweston], [1.12.90])
libweston_SONUM=27

This could also work, but Pekka's idea sounds more robust and simpler
in the long run. Add the logic once and don't bother checking/keeping
things in sync ;-)

Feels wrong to pollute configure.ac with code that tries to be
"smart" but is foremost disproportional in size to the problem. (And
you wonder why people hate $build_system_du_jour.) Would a commit
hook not be better to run a check that SONUM is in good shape w.r.t.
VERSION?

Emil Velikov

2016-07-11 14:44:32 UTC

Post by Jan Engelhardt
PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
...repeat the fun...
])]

Yes, it's one line of fun for each version that you want to be
compatible with. It's not ideal, but it's a price to pay, for keeping
things compatible/sane.

Without pkgconfig supporting some new alias tag (hint, hint) to cover
such a case,

No idea what such a "alias tag" is supposed to do/look like. Do you
have examples ?

Post by Jan Engelhardt
I predict that whoever uses libfoo-LotsANumbersHere
limits themselves to 3 or maybe 4 PKG_CHECK_MODULES calls, because it
is looking real silly.

If (and that's a _huge_ if) they support more than 3-4 versions of
libfoo, then the configure.ac will be the least ugly thing.

It's fine to disagree. From what I've seen working with package
maintainers and other my own experience, most people (still) share the
sentiments mentioned in the page.

Trying to get some understanding about your experience in the area -
which distribution(s) do you work with, how many packages do you
maintain ?

This could also work, but Pekka's idea sounds more robust and simpler
in the long run. Add the logic once and don't bother checking/keeping
things in sync ;-)

Feels wrong to pollute configure.ac with code that tries to be
"smart" but is foremost disproportional in size to the problem.

One could handle this in multiple ways - in configure, separate script
and/or hooks.

Post by Jan Engelhardt
(And
you wonder why people hate $build_system_du_jour.) Would a commit
hook not be better to run a check that SONUM is in good shape w.r.t.
VERSION?

As _everything_ in life, people hate X because they don't understand
it. Once your project gets complex enough and your build system is
comprehensive enough to handle it things always looks scary/nasty.

But all of that is an orthogonal, imho.

-Emil

Jan Engelhardt

2016-07-11 16:58:32 UTC

Post by Emil Velikov
http://ometer.com/parallel.html. I would strongly recommend giving it
a look.

Trying to get some understanding about your experience in the area -
which distribution(s) do you work with, how many packages do you
maintain ?

openSUSE. Enlisted for 441, but my id appears in 2056 changelogs by now and I
bear the role of global co-reviewer, i.e. some 9100 packages.

And in the paid part of life: SLE, RH6,7, Ubu14/16, Univention, Collax (things
you never heard of), Windows(*). So I am also aware about _their_
skeletons-in-the-closet.

(*) Not a distro, but an anarchy, which is also interesting to distribute for.

Emil Velikov

2016-07-11 21:23:49 UTC

Post by Emil Velikov
http://ometer.com/parallel.html. I would strongly recommend giving it
a look.

Trying to get some understanding about your experience in the area -
which distribution(s) do you work with, how many packages do you
maintain ?

openSUSE. Enlisted for 441, but my id appears in 2056 changelogs by now and I
bear the role of global co-reviewer, i.e. some 9100 packages.
And in the paid part of life: SLE, RH6,7, Ubu14/16, Univention, Collax (things
you never heard of), Windows(*). So I am also aware about _their_
skeletons-in-the-closet.

Damn, that's an impressive way of making me eat my own words ;-)

Strange part is that neither of Fedora, Debian, Gentoo + Arch plus the
Openhub $distro packages shows any results :-\ Guess I failed "at
googling"

That said, considering the discussion/confusion with others I'd
suspect you've been at our level way back. Thus some of our
assumptions/knowledge might be quite noobish. If you can
share/recommend some reading material that covers your earlier/current
concerns that'll be amazing.

Thanks
Emil

[1] https://admin.fedoraproject.org/pkgdb/packagers/
[2] https://nm.debian.org/public/people
[3] https://www.gentoo.org/inside-gentoo/developers/
[4] https://www.archlinux.org/people/developers/

Post by Jan Engelhardt
(*) Not a distro, but an anarchy, which is also interesting to distribute for.

Windows distribution is interesting in it's own crazy way :-P MSI,
NSIS, InstallShield, downloading MS C/.NET runtimes... heh memories.

Jan Engelhardt

2016-07-12 00:58:14 UTC

Post by Jan Engelhardt
Without pkgconfig supporting some new alias tag (hint, hint) to cover
such a case,

No idea what such a "alias tag" is supposed to do/look like. Do you
have examples ?

Proposed concept would be to make pkgconfig recognize
a new Alias directive:
gtk-2.0.pc:
Name: gtk-2.0
Version: 2
Alias: gtk
@OTHER_TYPICAL_FIELDS@
gtk-3.0.pc:
Name: foo-3.0
Version: 3
Alias: gtk
Result (recap):
A single PKG_CHECK_MODULESM([gtk], [gtk >= 2]) call may be used instead of
the usual two or more.

Post by Jan Engelhardt
I predict that whoever uses libfoo-LotsANumbersHere
limits themselves to 3 or maybe 4 PKG_CHECK_MODULES calls, because it
is looking real silly.

If (and that's a _huge_ if) they support more than 3-4 versions of
libfoo, then the configure.ac will be the least ugly thing.

Heh, true: The projects which do use foo-N.pc naming move about in
slow cycles (we had dbus-1, gtk-2, libnl-3 for a long time now), and
if they change, it can be assured they threw *everything* over the
fence.

Those who have just foo.pc are kind of the Linux kernel type: it
changes a bit here and there, and every now and then, and external
components with new failed builds are comparatively easily fixable.

This should not be overdiscussed; just pick something already. {1:
Either it will work out, and all is good, or it will not work out,
gets changed and then goto 1.} :p
^ That always worked out so far.

Quentin Glidic

2016-07-10 11:13:23 UTC

Post by Jan Engelhardt
First, what kind of parallel installability is sought?
* just runtime
* parallel development environment (like what e.g. libabw,
librevenge.. do)

everything that is about libweston including development enviroment
has been my idea.

Post by Jan Engelhardt
Few projects ever go to the length of making their /usr/include
headers or .pc files coinstallable by including some version number in
it.

Is there any particular downside of going all the way?

For example, if a program supports being built for gtk2 and gtk3,
it can't simply do
PKG_CHECK_MODULES([gtk], [gtk >= 2])
because the developers chose to stick the version in the basename :-(
Which means that someone has to do
PKG_CHECK_EXISTS([gtk-2.0], [PKG_CHECK_MODULES([gtk], [gtk-2.0])], [
PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
...repeat the fun...
])]
Now with gtk it was not so much a problem (yet!) because there
are only two different basenames in 15-or-so years.
But if weston wants to go to 27 "soon" (...)

If we install only one .pc file:
- You cannot develop against an old version. And that means older
version *than your distribution libweston*. Or we add the burden or
developer to build older versions in their own environment, messing with
PKG_CONFIG_PATH and stuff.
- Users won’t be able to build your project once you hit an API removal.

If libweston goes fast enough, compositor projects will just skip a few
versions here and then, and eventually drop (some) old versions support,
so the configure.ac check will not grow like crazy.

There are two kind of distributions: rolling release and versioned release.
The former will just include whatever versions are needed by compositor
projects.
The latter will mandate some versions that compositors will have to
support to be in these distributions. If there are enough users,
distributions will probably patch them to support the shipped libweston
version anyway.

Post by Pekka Paalanen
- MAJOR will start running like hell, we'll probably get to weston
27.0.0 before it slows down, or whatever

- if just parallel runtime is the goal: done deal, just bump
the SO/ABI version (libfoo.so.2, .so.3), no one cares about
how high they go

We also have plugins and other stuff, to be scoped by installation
directory.
Wouldn't that cause installations to have a libfoo.so symlink
without a version number? That we do not want, a too high risk of
pointing to a wrong version.

The versionless .so goes with versionless .pc. If ld cannot pick the .so
you expect, things will explode.

As for plugins, the concern was for loading the correct ones.
libmirage (from Arch Linux[1]) has /usr/lib/libmirage-3.0 (and
/usr/include/libmirage-3.0), so they do have the version in their path.

Or you can just have two lines in configure.ac next to each other
which will scream at you "update me in lockstep" everytime you look
at them because you modify one of them.
AC_INIT([libweston], [1.12.0])
libweston_SONUM=3
->
AC_INIT([libweston], [1.12.90])
libweston_SONUM=27

I’d do some m4 magic. We have a well-defined versioning scheme (.90
post-release bump) that can be automated, why not make use of it?

Cheers,

[1] <https://www.archlinux.org/packages/community/x86_64/libmirage/>

--
Quentin “Sardem FF7” Glidic

Jan Engelhardt

2016-07-10 12:34:28 UTC

Post by Quentin Glidic
- You cannot develop against an old version.

I do not feel that is true. If you have Berkeley DB 4.5 in tarball
form, you can build and `make install` it. Provided the SONAME is
different (it is; libdb-4.5.so), it *ought* not to break the rest of
your system which relies on libdb-4.8.so.

If you have db 4.5 in distropackage form, you can install the
libdb-4_5.rpm library, and it won't kick out libdb-4_8, and you can
install libdb-4_5-devel.rpm, which only kicks out libdb-4_8-devel,
but that is a negligible fact, as distro build results show that
no one seriously needs 4.5 and 4.8 at the same time a particular
software component is built.

The example extends to packages other than bdb. (bdb has no .pc
file, which is the same complexity class a one .pc file.)

Pekka Paalanen

2016-07-13 11:54:19 UTC

On Sun, 10 Jul 2016 14:34:28 +0200 (CEST)

Post by Quentin Glidic
- You cannot develop against an old version.

I do not feel that is true. If you have Berkeley DB 4.5 in tarball
form, you can build and `make install` it. Provided the SONAME is
different (it is; libdb-4.5.so), it *ought* not to break the rest of
your system which relies on libdb-4.8.so.
If you have db 4.5 in distropackage form, you can install the
libdb-4_5.rpm library, and it won't kick out libdb-4_8, and you can
install libdb-4_5-devel.rpm, which only kicks out libdb-4_8-devel,
but that is a negligible fact, as distro build results show that
no one seriously needs 4.5 and 4.8 at the same time a particular
software component is built.
The example extends to packages other than bdb. (bdb has no .pc
file, which is the same complexity class a one .pc file.)

Hi Jan,

I think Quentin raised a good point, though. In source-based
distros, well, in Gentoo at least which I use almost exclusively,
there are no separate -devel packages.

I haven't even looked at how Gentoo would solve the issue where you
cannot install multiple versions of library headers to allow
installing (which implies building from source) two different
programs each depending on the different version of the library and
headers.

Would it be so bad to assume that compositor projects would not
bother supporting more than one (or few at most) libweston MAJOR at
a time?

OTOH, would adding a new libweston MAJOR in an already stable and
released binary distribution be absolutely forbidden? It would by
definition not affect anything the distribution was released with,
unless libweston's dependencies changed, but I think the
dependencies might change less often than we bump MAJOR.

I believe the burden of adding pkg-config checks will be
insignificant compared to the work needed for a compositor project
to actually work with multiple libweston MAJORs.

It's good have a seasoned packager like you (thanks for the
introduction, puts your comments in whole different perspective for
me!) to comment on these things. There are more issues I'd like
someone to sanity-check after this versioning issue gets resolved.
It would essentially boil down to checking Weston's README for the
packager notes if they make sense as a plan, and what we could do to
help packaging.

In summary, the only downside from installing all devel files
MAJOR-specific is that user projects need multiple pkg-config
checks if they want to support multiple MAJORs, right?

I'd vote for taking that hit and seeing if anyone complains loud
enough.

Thanks,
pq

Jan Engelhardt

2016-07-13 14:53:27 UTC

Post by Pekka Paalanen
I think Quentin raised a good point, though. In source-based
distros, well, in Gentoo at least which I use almost exclusively,
there are no separate -devel packages.

A package is, abstractly, merely a selected subset of `make install`
artifacts. As such, you could install a -devel package (file set)
even on a distro which has "no -devel packages", and in fact, you can
just extend the thought to a distribution which has no concept
"packages" at all.

In other words, there is always a way to install libdb-4_5-devel, and
uninstall it again in case one needs to make room for libdb-4_8-devel.

Post by Pekka Paalanen
Would it be so bad to assume that compositor projects would not
bother supporting more than one (or few at most) libweston MAJOR at
a time?

On the contrary. As a distro package recipe maintainer, you have to even
_expect_ it will happen that a compositor requires exactly one specific
version of libweston. (Like demonstrated, libdb already shows
why/how solved.)

Post by Pekka Paalanen
OTOH, would adding a new libweston MAJOR in an already stable and
released binary distribution be absolutely forbidden? It would by
definition not affect anything the distribution was released with,
unless libweston's dependencies changed, but I think the
dependencies might change less often than we bump MAJOR.

What the distro permits is a matter of their policy. Nothing you
should be concerned about, because what you do is just regularly
releasing new versions of your software.

Post by Pekka Paalanen
In summary, the only downside from installing all devel files
MAJOR-specific is that user projects need multiple pkg-config
checks if they want to support multiple MAJORs, right?
I'd vote for taking that hit and seeing if anyone complains loud
enough.

Well, my complaint would be:

I would want that compositors at the distro level to build against
the latest libweston, assuming it succeeds. If the compositor however
has a PKG_C_M([libweston-15]) check, I would have to update that line
with a patch _everytime a new libweston is out_, to 16, 17, .... This
is why I am supporting the "do NOT version the pkgconfig filename,
and see if anyone complains" approach. With the unversioned approach,
if the build were not to succeed with 16/17/+, I only need to
make/edit a patch that changes PKG_C_M([libweston]) to [libweston-15]
_once_, and maybe revisited if and when the compositor finally
catches up.

Emil Velikov

2016-07-14 15:33:39 UTC

Post by Pekka Paalanen
I think Quentin raised a good point, though. In source-based
distros, well, in Gentoo at least which I use almost exclusively,
there are no separate -devel packages.

A package is, abstractly, merely a selected subset of `make install`
artifacts. As such, you could install a -devel package (file set)
even on a distro which has "no -devel packages", and in fact, you can
just extend the thought to a distribution which has no concept
"packages" at all.
In other words, there is always a way to install libdb-4_5-devel, and
uninstall it again in case one needs to make room for libdb-4_8-devel.

The keypoint here is that one should _not_ need to uninstall
libdb-4_5-devel in order to have libdb-4_8-devel and vice-versa.
One must be able to just "make install" for each (major) version and
_nothing_ should be overwritten. This is what parallel installability
is all about (afaict).

Looking at the OpenSuse libdb packages [1] [2] it shows that:
- the -devel packages will _explicitly conflict_ with one another (as
you mentioned/suggested above). Thus this approach won't fly with
source-based distros.
- you guys install 4.5 and 4.8 headers in /usr/include/db4/ as
opposed to the upstream /usr/include/
- each package -devel package installs conflicting headers, and
symlinks (libdb.so, libdb-${major}.so and equivalent)
- there's a handful of source code modifications to accommodate the above.

[1] https://build.opensuse.org/package/view_file/openSUSE:Factory/libdb-4_5/libdb-4_5.spec?expand=1
[2] https://build.opensuse.org/package/view_file/openSUSE:Factory/libdb-4_8/libdb-4_8.spec?expand=1

Post by Pekka Paalanen
Would it be so bad to assume that compositor projects would not
bother supporting more than one (or few at most) libweston MAJOR at
a time?

With the above things said libdb package(s), I would strongly suggest
against giving it/them as an example.

If you look closely at some (many?) of the GTK/Qt based applications
you'll see that they support multiple versions of the respective
toolkit. Some even support multiple version of GTK _and_ Qt at the
same time. This is exactly what's happening (being suggested) here.
Sure that means a possibility for greater permutation, more packages
to ship, maintain and test. All of those are/should be selectable at
configure time and the final decision is up-to the distros.

What the distro permits is a matter of their policy. Nothing you
should be concerned about, because what you do is just regularly
releasing new versions of your software.

True. That doesn't stop him (anyone else involved) from trying to
understand the distro needs as opposed to completely ignoring them.

I would want that compositors at the distro level to build against
the latest libweston, assuming it succeeds. If the compositor however
has a PKG_C_M([libweston-15]) check, I would have to update that line
with a patch _everytime a new libweston is out_, to 16, 17, ....

Wrong, I'm afraid. You (as a distro) will chose which versions of
libweston will be shipped, and thus your software will be build
against it/them.

If that means that project A (requires too new version) and/or B
(requires too old version) may no be available. Yes, it will be
annoying if projects that you guys want to use/ship don't update
against newer libweston but that's nothing to blame on libweston. Just
communicate your points cleanly with the respective projects.

The alternative is to follow the current GTK approach and
(un)intentionally break API/ABI _between minors_. Which is a serious
no go, imho.

Post by Jan Engelhardt
This
is why I am supporting the "do NOT version the pkgconfig filename,
and see if anyone complains" approach. With the unversioned approach,
if the build were not to succeed with 16/17/+, I only need to
make/edit a patch that changes PKG_C_M([libweston]) to [libweston-15]
_once_, and maybe revisited if and when the compositor finally
catches up.

In general I would strongly suggest against making any long term local
source code modifications. That's not because you lack the skills
and/or knowledge (I've looked at your kernel work). Wherever possible
help projects out, by a) lobbying that they keep/add support for
version X and/or b) just send them a patch "I've added support for the
new version XX of YY". Pretty sure they'll be happy to see the latter
more ;-)

IMHO the alias suggestion sounds quite reasonable, yet afaict
pkg-config does not support it. Have you mentioned/suggested it to the
pkgconfig developers ?

TL;DR
* libdb is a classic example of _not_ parallel installable library and
the OpenSuse packaging shows the efforts needed to make it one (sort
of).
* Having multiple libweston{major} will be annoying for
distribution(s) _if_ projects using libweston do not align the
version(s) they [can] use with the one(s) provided by distros.
* The latter of which should be coordinated between the distros and
said projects.

Regards,
Emil

Jan Engelhardt

2016-07-15 00:02:29 UTC

Post by Emil Velikov
The keypoint here is that one should _not_ need to uninstall
libdb-4_5-devel in order to have libdb-4_8-devel and vice-versa.
This is what parallel installability is all about (afaict).

It is indeed what it is about.
But is it _necessary_ to have? No (IMO).
Convenient? Possibly.

Perhaps I am biased because all packages that can be built can be
built in a clean namespace where the "right" devel versions are
installed. Whether that is in a source-based distro (what a weird name,
all distros are using source somewhere) or not.

Post by Emil Velikov
If you look closely at some (many?) of the GTK/Qt based applications
you'll see that they support multiple versions of the respective
toolkit. Some even support multiple version of GTK _and_ Qt at the
same time. This is exactly what's happening (being suggested) here.

I will argue that they are slow moving targets (you can add wxWidgets
to the list). That's not the kind of bell that was sounded for
libweston ("be at 27 soon").

Post by Emil Velikov
The alternative is to follow the current GTK approach and
(un)intentionally break API/ABI _between minors_. Which is a serious
no go, imho.

An AxI break is (to be) communicated by SONAME change. If they do
that for a tarball minor, well let them. What's in a release number
anyway? The Linux kernel also "changes their ABI" between minors.

Post by Emil Velikov
IMHO the alias suggestion sounds quite reasonable, yet afaict
pkg-config does not support it. Have you mentioned/suggested it to the
pkgconfig developers ?

Nope.

Post by Emil Velikov
TL;DR
* libdb is a classic example of _not_ parallel installable library and
the OpenSuse packaging shows the efforts needed to make it one (sort
of).

The only effort was parallel runtime installability.

Pekka Paalanen

2016-07-15 13:30:00 UTC

On Wed, 13 Jul 2016 16:53:27 +0200 (CEST)

Post by Pekka Paalanen
I think Quentin raised a good point, though. In source-based
distros, well, in Gentoo at least which I use almost exclusively,
there are no separate -devel packages.

A package is, abstractly, merely a selected subset of `make install`
artifacts. As such, you could install a -devel package (file set)
even on a distro which has "no -devel packages", and in fact, you can
just extend the thought to a distribution which has no concept
"packages" at all.
In other words, there is always a way to install libdb-4_5-devel, and
uninstall it again in case one needs to make room for libdb-4_8-devel.

Hi Jan,

that sounds to me as "you can do whatever you want, just write the
code." True, and unhelpful. I could waste gigabytes of disk and
days of CPU time just to set up a "clean build environment" for
installing a single program, but I won't and Gentoo doesn't.
(Setting up each dependency implies building that from source.)

Gentoo does not have a "clean build environment" at all. Everything
gets built against what is actually installed in the system. If a
program to be installed needs a dependency only for building, that
dependency will be first installed *in the running system*, not in
some staged "clean namespace".

You can call that a defect in Gentoo, but that's how it rolls.

I sure would wish libweston to be packaged in Gentoo in a way that
you can also install several different compositors requiring
different libweston majors at the same time. But if we don't
implement that parallel-installability already in upstream, I
believe no-one will bother patching it for Gentoo. And if they
patch it, why shouldn't we take those patches upstream then?

Post by Pekka Paalanen
Would it be so bad to assume that compositor projects would not
bother supporting more than one (or few at most) libweston MAJOR at
a time?

Umm, I suppose we agree here?

I just meant that user projects would not have too many pkg-config
checks since they wouldn't support too many libweston majors at a
time. I expect users to abandon old libweston major when migrating
to a new one because maintaining the alternate paths is too much
work and confusion.

What the distro permits is a matter of their policy. Nothing you
should be concerned about, because what you do is just regularly
releasing new versions of your software.

That's true about policy, yes, but I'm getting a strange vibe here.
You too seem to advocate ignoring distributions rather than taking
them into account.

<off-topic>

This is the second time I have been turned down for trying
to figure out what distributions would like to have from the
upstream. It's as if packagers were actually happy dealing with
projects making their distribution work hard and having to
maintain intrusive, sketchy patches just to get the thing built and
installed in the right places.

The earlier time was when I though that avoiding circular
dependencies between projects/packages was a good thing, and I got
told "why would you even care about that, distributions can deal
with it". (Not by anyone on this thread.)

Yes, you can deal with anything. Wouldn't you rather avoid pain
though?

</off-topic>

I would want that compositors at the distro level to build against
the latest libweston, assuming it succeeds. If the compositor however

The assumption is the wrong way. You must assume that if major
changes the build will fail or at least running will fail.

Post by Jan Engelhardt
has a PKG_C_M([libweston-15]) check, I would have to update that line

I would never expect a packager to change the check. That is why we
want to make libweston parallel-installable with different majors,
and we want to do that upstream, so that it would be easier for all
distributions to have it parallel-installable rather than not.

Post by Jan Engelhardt
with a patch _everytime a new libweston is out_, to 16, 17, .... This

Having to update that explicitly is the whole point. We bumped the
major, you have to re-review all your code to see if it still
works. Changing the number is insignificant compared to your other
worries.

Post by Jan Engelhardt
is why I am supporting the "do NOT version the pkgconfig filename,
and see if anyone complains" approach. With the unversioned approach,
if the build were not to succeed with 16/17/+, I only need to
make/edit a patch that changes PKG_C_M([libweston]) to [libweston-15]
_once_, and maybe revisited if and when the compositor finally
catches up.

User projects cannot predict how libweston will change in a future
release, therefore they should *by default* depend on a specific
major and reject all other majors, less or greater.

I must be misunderstanding a whole lot of things, because to me it
sounds like you want us to maximize the burden on packagers. I
suppose other packagers might agree, but it will also hit
developers and anyone wanting to build compositors (not libweston)
from source manually, and the latter people are those we *really*
need for getting libweston forward.

In summary, yes, I suppose we should ignore distributions and do
what we think might be best for the people we target: developers
foremost, and end-users the second. Packagers can always patch
things any way they want.

I also think that what 'make install' produces should be the
upstream recommended file/directory layout for all installations.

Thanks,
pq

Jan Engelhardt

2016-07-15 16:11:57 UTC

What the distro permits is a matter of their policy. Nothing you
should be concerned about, because what you do is just regularly
releasing new versions of your software.

That's true about policy, yes, but I'm getting a strange vibe here.
You too seem to advocate ignoring distributions rather than taking
them into account. [...]
This is the second time I have been turned down for trying
to figure out what distributions would like to have from the
upstream.

Well let me rephrase it then. In openSUSE, adding a package to the
update channel (bugfix channel) is possible, as is doing so with new
SONAME, as we support selectively rebuilding packages (already have
to do that because of the kernel's unstability guarantee).

But I probably would not normally ship a new shiny libweston with new
features and new APIs in the bugfix channel, so whatever new release
may be available at freedesktop.org, it would have to wait for the
next distro release.

So it's not really a turn-down, but I just do not have anything
to request from upstream with regard to releases.

Post by Pekka Paalanen
The earlier time was when I though that avoiding circular
dependencies between projects/packages was a good thing, and I got
told "why would you even care about that, distributions can deal
with it". (Not by anyone on this thread.)

There are so many upstreams, not all of which are welcoming changes
proposed that would benefit distros (mixture of don't know how to
implement, don't know how to maintain if implemented, don't care, or
not-interested). Then all we can do is workaround at the distro
level, especially if the package is essential. Think util-linux
which, in fully populated mode, has a cycle with systemd, which we
had to end by building it multiple times as things become
available. Not sure whatelse to have done there.

Pekka Paalanen

2016-07-17 08:55:45 UTC

On Fri, 15 Jul 2016 18:11:57 +0200 (CEST)

What the distro permits is a matter of their policy. Nothing you
should be concerned about, because what you do is just regularly
releasing new versions of your software.

Well let me rephrase it then. In openSUSE, adding a package to the
update channel (bugfix channel) is possible, as is doing so with new
SONAME, as we support selectively rebuilding packages (already have
to do that because of the kernel's unstability guarantee).
But I probably would not normally ship a new shiny libweston with new
features and new APIs in the bugfix channel, so whatever new release
may be available at freedesktop.org, it would have to wait for the
next distro release.

Hi Jan,

I can totally agree with that. Particularly as you probabably
wouldn't include a compositor needing a new libweston on a bugfix
channel either, right? A compositor bumping its libweston major
requirement is not a bug fix by definition, so there's no
problem.

If there is a demand for bugfix releases on old major releases, I
believe we would do those, provided backporting the fix is not too
hard. But I also think users need to ask for that, since otherwise
it would be better to just concentrate on getting libweston
actually stabilized. Some way to advertise the "please do ask" would
probably be necessary from weston upstream.

In fact, this is what we already do with the stable branches of
weston and wayland - they don't see any attention if no-one asks
for it. It would be even better if we got help with them from the
people that would need them.

Post by Jan Engelhardt
So it's not really a turn-down, but I just do not have anything
to request from upstream with regard to releases.

Ok, sorry for the confusion.

Thanks,
pq

Quentin Glidic

2016-07-04 14:37:15 UTC

Post by Emil Velikov
Hi all,
Here is a respin of the earlier series which changes how libweston is
named, and thus shipped. I believe all the logic/reasoning is explicitly
stated, although if something feels amiss, please let me know.
NOTE: WARNING: The series exposes a fatal bug in weston thus the tests
fail to build (let alone run).
Namely: atm some/many of the modules are built with unresolved symbols.
Is that a bug or by design ? From a quick look it seems to be the
latter.
If anyone is interested in resolving this please grep through mesa for
"no-undefined" - it handles both -no-undefined and -Wl,--no-undefined in
a portable manner.

You cannot really fix all of them.
We should link all modules to libweston, but for weston-specific
modules, using weston-specific functions, they will always be unresolved
at build-time.

Cheers,

--
Quentin “Sardem FF7” Glidic

Pekka Paalanen

2016-07-04 14:55:36 UTC

On Mon, 4 Jul 2016 15:23:48 +0100

Hi Emil,

what unresolved symbols?

You mean the symbols that are resolved from Weston the executable?

Or maybe the symbols that libweston exports, and test modules expect to
be present without actually linking to libweston?

Yeah, all that needs to be fixed in time. Should we link all modules to
libweston? I'd assume that should fix almost all of them, but I haven't
looked yet.

Obviously we cannot land patches that break the tests.

Post by Emil Velikov
If anyone is interested in resolving this please grep through mesa for
"no-undefined" - it handles both -no-undefined and -Wl,--no-undefined in
a portable manner.

Preferably all the binaries we build would be using no-undefined. It
was not possible before libweston because weston the executable
provided lots of them, but now it should be achievable and a very good
improvement in catching stupid bugs.

Thanks,
pq

Emil Velikov

2016-07-04 15:17:08 UTC

Post by Pekka Paalanen
On Mon, 4 Jul 2016 15:23:48 +0100

Hi Emil,
what unresolved symbols?

For the exact list check your system weston with ldd -r foo. For
example on my Arch setup with weston 1.10.0-1

$ ldd -r /usr/lib/weston/* | grep undefined | wc -l

$ ldd -r /usr/lib/weston/* | grep undefined | head
undefined symbol: weston_log (/usr/lib/weston/cms-colord.so)
undefined symbol: weston_log (/usr/lib/weston/cms-static.so)
undefined symbol: zwp_input_panel_v1_interface
(/usr/lib/weston/desktop-shell.so)
undefined symbol: zwp_input_panel_surface_v1_interface
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_stable_fade_run
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_compositor_schedule_repaint
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_surface_set_size
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_move_scale_run (/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_matrix_multiply
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_install_debug_key_binding
(/usr/lib/weston/desktop-shell.so)

Post by Pekka Paalanen
You mean the symbols that are resolved from Weston the executable?

I'd imagine so.

Post by Pekka Paalanen
Or maybe the symbols that libweston exports, and test modules expect to
be present without actually linking to libweston?
Yeah, all that needs to be fixed in time. Should we link all modules to
libweston? I'd assume that should fix almost all of them, but I haven't
looked yet.
Obviously we cannot land patches that break the tests.

Agree. Sadly things were already broken before I came - my changes
only exposed the existing bugs(?).

Post by Emil Velikov
If anyone is interested in resolving this please grep through mesa for
"no-undefined" - it handles both -no-undefined and -Wl,--no-undefined in
a portable manner.

From a quick look - most symbols are (should come) from libweston now
that we have it. Although there's a bunch of generated ones, which I'm
not sure about.

It'll be great if someone with more weston/wayland experience than me,
takes a look (at the output of ldd) and categorises them. Then myself
and/or others can divide and concur.

Cheers,
Emil

Pekka Paalanen

2016-07-05 14:54:47 UTC

On Mon, 4 Jul 2016 16:17:08 +0100

Post by Pekka Paalanen
On Mon, 4 Jul 2016 15:23:48 +0100

Hi Emil,
what unresolved symbols?

For the exact list check your system weston with ldd -r foo. For
example on my Arch setup with weston 1.10.0-1
$ ldd -r /usr/lib/weston/* | grep undefined | wc -l
$ ldd -r /usr/lib/weston/* | grep undefined | head
undefined symbol: weston_log (/usr/lib/weston/cms-colord.so)
undefined symbol: weston_log (/usr/lib/weston/cms-static.so)
undefined symbol: zwp_input_panel_v1_interface
(/usr/lib/weston/desktop-shell.so)
undefined symbol: zwp_input_panel_surface_v1_interface
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_stable_fade_run
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_compositor_schedule_repaint
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_surface_set_size
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_move_scale_run (/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_matrix_multiply
(/usr/lib/weston/desktop-shell.so)
undefined symbol: weston_install_debug_key_binding
(/usr/lib/weston/desktop-shell.so)

Post by Pekka Paalanen
You mean the symbols that are resolved from Weston the executable?

I'd imagine so.

Agree. Sadly things were already broken before I came - my changes
only exposed the existing bugs(?).

Hi Emil,

depends on your definition of broken. We have been compiling and
running the test suite just fine all the time, both before and after
the patch that added libweston.so.