On 10/07/2016 12:11, Jan Engelhardt wrote:
On Saturday 2016-07-09 18:24, Pekka Paalanen wrote:
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.
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.
- 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)
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.
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
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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
