[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Default behaviour for including plugins
From:       Alex Turbov <i.zaufi () gmail ! com>
Date:       2019-07-26 16:29:18
Message-ID: CANktQtsjGE1gSCjws=dyRYyJz7S7Qzzrg_2VaYhJH4bY8bGGrA () mail ! gmail ! com
[Download RAW message or body]

Just a suggestion:

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...


On Fri, Jul 26, 2019 at 7:02 PM Christoph Cullmann <christoph@cullmann.io>
wrote:

> On 2019-07-26 17:40, Daan De Meyer wrote:
> > Hi,
> >
> > I was thinking about the best way to handle plugin building during
> > further refactoring of the CMake scripts. Right now, some stuff is
> > built implicitly depending on whether certain libraries are found or
> > not (see addons/CMakeLists.txt). I was wondering if this shouldn't be
> > made explicit instead, with each plugin either being turned on/off
> > explicitly in the CMake script which determines whether it gets built
> > or not.
> >
> > Making building of plugins explicit prevents hard to trace builds
> > where a default build succeeds on two machines but may differ in
> > features from one machine to another depending on what other libraries
> > are installed.
> >
> > To achieve this, I could add an optional second parameter to
> > `ecm_add_optional_subdirectory` which takes ON/OFF as its value (just
> > like CMake's `option` command) and initializes the default value of
> > `ecm_add_optional_subdirectory`'s `BUILD_${_dir}` to that value. The
> > optional value would default to `ON` if not provided to keep backwards
> > compatibility.
> >
> > Most plugins would be enabled by default so as  to not change anything
> > substantial for users but some plugins with more exotic dependencies
> > might be disabled by default instead.
> >
> > Any thoughts?
>
> Hi,
>
> I would strongly prefer the current way. You get info which optional
> stuff is missing, no need to hide some plugins per default.
>
> Optional dependencies are common and people are used to check for that
> output but not to search for some "please enable this plugin" extra
> switches.
>
> Greetings
> Christoph
>
> >
> > Regards,
> >
> > Daan
>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org
>

[Attachment #3 (text/html)]

<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 &#39;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 &lt;<a \
href="mailto:christoph@cullmann.io">christoph@cullmann.io</a>&gt; \
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> &gt; Hi,<br>
&gt; <br>
&gt; I was thinking about the best way to handle plugin building during<br>
&gt; further refactoring of the CMake scripts. Right now, some stuff is<br>
&gt; built implicitly depending on whether certain libraries are found or<br>
&gt; not (see addons/CMakeLists.txt). I was wondering if this shouldn&#39;t be<br>
&gt; made explicit instead, with each plugin either being turned on/off<br>
&gt; explicitly in the CMake script which determines whether it gets built<br>
&gt; or not.<br>
&gt; <br>
&gt; Making building of plugins explicit prevents hard to trace builds<br>
&gt; where a default build succeeds on two machines but may differ in<br>
&gt; features from one machine to another depending on what other libraries<br>
&gt; are installed.<br>
&gt; <br>
&gt; To achieve this, I could add an optional second parameter to<br>
&gt; `ecm_add_optional_subdirectory` which takes ON/OFF as its value (just<br>
&gt; like CMake&#39;s `option` command) and initializes the default value of<br>
&gt; `ecm_add_optional_subdirectory`&#39;s `BUILD_${_dir}` to that value. The<br>
&gt; optional value would default to `ON` if not provided to keep backwards<br>
&gt; compatibility.<br>
&gt; <br>
&gt; Most plugins would be enabled by default so as   to not change anything<br>
&gt; substantial for users but some plugins with more exotic dependencies<br>
&gt; might be disabled by default instead.<br>
&gt; <br>
&gt; 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 &quot;please enable this plugin&quot; extra <br>
switches.<br>
<br>
Greetings<br>
Christoph<br>
<br>
&gt; <br>
&gt; Regards,<br>
&gt; <br>
&gt; 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>



[prev in list] [next in list] [prev in thread] [next in thread]