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

[Pekka Paalanen]

On Wed, 28 Jan 2015 11:13:39 +0200
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

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

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

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

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

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

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


Thanks,
pq