From kwrite-devel Fri Jul 26 16:29:18 2019 From: Alex Turbov Date: Fri, 26 Jul 2019 16:29:18 +0000 To: kwrite-devel Subject: Re: Default behaviour for including plugins Message-Id: X-MARC-Message: https://marc.info/?l=kwrite-devel&m=156415857929826 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--000000000000e33615058e980b06" --000000000000e33615058e980b06 Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000e33615058e980b06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a suggestion:

but distr= omakers may prefer to build a plugin-per-package way and it could help to h= ave an option(s) to disable everything 'cept one particular plugin...


On Fri, Jul 26, 2019 at 7:02 PM Christoph Cullmann <<= a href=3D"mailto:christoph@cullmann.io">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<= br> > 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<= br> > like CMake's `option` command) and initializes the default value o= f
> `ecm_add_optional_subdirectory`'s `BUILD_${_dir}` to that value. T= he
> optional value would default to `ON` if not provided to keep backwards=
> compatibility.
>
> Most plugins would be enabled by default so as=C2=A0 to not change any= thing
> 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" ext= ra
switches.

Greetings
Christoph

>
> Regards,
>
> Daan

--
Ignorance is bliss...
https:= //cullmann.io | https://kate-editor.org
--000000000000e33615058e980b06--