<div dir="auto">"may prefer" is too weak an argument to justify this change. We never had a complaint before.<div dir="auto"><br></div><div dir="auto">Best regards</div><div dir="auto">Dominik</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Alex Turbov <<a href="mailto:i.zaufi@gmail.com">i.zaufi@gmail.com</a>> schrieb am Fr., 26. Juli 2019, 18:29:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Just a suggestion:</div><div><br></div><div>but distromakers may prefer to build a plugin-per-package way and it could help to have an option(s) to disable everything 'cept one particular plugin...</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 26, 2019 at 7:02 PM Christoph Cullmann <<a href="mailto:christoph@cullmann.io" target="_blank" rel="noreferrer">christoph@cullmann.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2019-07-26 17:40, Daan De Meyer wrote:<br>
> Hi,<br>
> <br>
> I was thinking about the best way to handle plugin building during<br>
> further refactoring of the CMake scripts. Right now, some stuff is<br>
> built implicitly depending on whether certain libraries are found or<br>
> not (see addons/CMakeLists.txt). I was wondering if this shouldn't be<br>
> made explicit instead, with each plugin either being turned on/off<br>
> explicitly in the CMake script which determines whether it gets built<br>
> or not.<br>
> <br>
> Making building of plugins explicit prevents hard to trace builds<br>
> where a default build succeeds on two machines but may differ in<br>
> features from one machine to another depending on what other libraries<br>
> are installed.<br>
> <br>
> To achieve this, I could add an optional second parameter to<br>
> `ecm_add_optional_subdirectory` which takes ON/OFF as its value (just<br>
> like CMake's `option` command) and initializes the default value of<br>
> `ecm_add_optional_subdirectory`'s `BUILD_${_dir}` to that value. The<br>
> optional value would default to `ON` if not provided to keep backwards<br>
> compatibility.<br>
> <br>
> Most plugins would be enabled by default so as  to not change anything<br>
> substantial for users but some plugins with more exotic dependencies<br>
> might be disabled by default instead.<br>
> <br>
> Any thoughts?<br>
<br>
Hi,<br>
<br>
I would strongly prefer the current way. You get info which optional <br>
stuff is missing, no need to hide some plugins per default.<br>
<br>
Optional dependencies are common and people are used to check for that <br>
output but not to search for some "please enable this plugin" extra <br>
switches.<br>
<br>
Greetings<br>
Christoph<br>
<br>
> <br>
> Regards,<br>
> <br>
> Daan<br>
<br>
-- <br>
Ignorance is bliss...<br>
<a href="https://cullmann.io" rel="noreferrer noreferrer" target="_blank">https://cullmann.io</a> | <a href="https://kate-editor.org" rel="noreferrer noreferrer" target="_blank">https://kate-editor.org</a><br>
</blockquote></div>
</blockquote></div>