<div dir="ltr">On Tue, Jun 23, 2015 at 10:49 AM, Giulio Camuffo <span dir="ltr"><<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>Well, but you are adding weston specific stuff into the backends code,<br>
that is the options handling. In libweston the backends do not parse<br>
the command line or the config file, so all the backend options are<br>
weston specific.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.<br><br><br></div></div></div></div>