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

[Bill Spitzak]

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

On 02/05/2015 12:37 AM, Pekka Paalanen wrote:
> On Wed, 28 Jan 2015 11:13:39 +0200
> Giulio Camuffo <giuliocamuffo 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>