[PATCH weston] compositor: Separate hardcoded backend related code from compositor

[Giulio Camuffo]

2015-06-23 21:22 GMT+03:00 Bill Spitzak <spitzak at gmail.com>:
> On Tue, Jun 23, 2015 at 10:49 AM, Giulio Camuffo <giuliocamuffo at gmail.com>
> wrote:
>>
>> Well, but you are adding weston specific stuff into the backends code,
>> that is the options handling. In libweston the backends do not parse
>> the command line or the config file, so all the backend options are
>> weston specific.
>
>
> This just seems wrong to me. Why are these backends .so files at all, then?
> The compositor cannot load any it does not know about since it requires
> passing this option structure that it had to know about at compile time. It
> would be far more efficient to just link all of them into the compositor
> then and it would start up faster.

It is true that weston.c currently needs to know about the plugins at
compile time, however nobody stops another compositor (or weston) to
put the backend inititalization in its own plugins, and gain back
support for random backends, with one plugin for libweston and one
plugin for the compositor that inits the new backend. Going away with
the plugins in libweston would remove that possibility.
I agree it does not look perfect, but i'm not sure what better options
there are.

>
> It's true that this is not going to really kill anything, but it does suffer
> from code smell. Adding an option to a backend will require modifying a
> header file that compositors have to include (the one defining the option
> structure for that backend) and changing all compositors to set that option
> in the structure, as well as modifying the backend itself.

There is no header to modify, only a new one to add. If you go with
the compositor plugins as above you don't need to touch the main
compositor code.

>
> Passing a weston_options structure and letting the backend remove options it
> understands I think will work fine. That does not mean the compositor has to
> use the weston option parser to create the structure. And it certainly does
> not mean the backends are parsing the command line. The current ones are not
> being passed argv so this is obviously false.

The current backends (in master), do parse the command line, check again.
Anyway, all this is easily said, but my attempts at doing so failed.
My hope is that after we settle down with the initial break we will be
able to unify the backends api.

>
>