<div dir="ltr"><div>Alright, I can understand where you're coming from. However, I would then suggest we should apply the current approach consistently for each plugin by finding each plugin's dependencies in its CMake script and only building the plugin if all its dependencies are found. I'd move all the if tests and `set_package_properties` calls checks currently in addons/CMakeLists.txt to their respective plugin CMake scripts, leaving addons/CMakeLists.txt as a simple script only calling `ecm_add_optional_subdirectory` for each subdirectory in the addons directory. Each plugin CMake script then calls `find_package` to find its required dependencies and only continues with the rest of its script if all its dependencies are found.</div><div><br></div><div>These changes should make plugin CMake scripts more consistent and localized which makes debugging and developing new plugins easier.</div><div><br></div><div>Regards,</div><div><br></div><div>Daan<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 26 Jul 2019 at 18:02, Christoph Cullmann <<a href="mailto:christoph@cullmann.io" target="_blank">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" target="_blank">https://cullmann.io</a> | <a href="https://kate-editor.org" rel="noreferrer" target="_blank">https://kate-editor.org</a><br>
</blockquote></div>