Continuing from a few thoughts I launched on the original T10209, mainly aimed at keeping the project configuration dialog's left side-bar as unencumbered as possible. I think the current plugin could be merged into the customdefinesandincludes plugin because it provides a programmatic way to add include paths and/or defines.

blackwarthog added a comment.

> You'll get more feedback on this when you present your patch via a differential (aka "patch") review.

Already https://phabricator.kde.org/D17794
Sorry, it was my misunderstanding. May i suggest to add link to these instructions <https://community.kde.org/Infrastructure/Phabricator> to this page <https://www.kdevelop.org/contribute-kdevelop> :)

'custom-definesandincludes' provides generic functionality for injection of cuctom includes and defines into build and indexing sequence. This functionality uses by CMake, Make and other build plugins.

Are you certain that information is used for anything other than parsing? That would mean the heading in the side bar (Language Support) isn't a very happy choice.

OTOH, if you're right, certain of the build managers could benefit just like the parser from relevant information injected through pkgconfig, meaning this is actually an argument in favour of patching the customdefines* plugin rather than adding another one.

Pkgconfig functionality is more specialized and not always applicable for MacOS and windows, required to run third-party application etc. So, i think it is not good idea to merge these plugins into one.

A project either requires pkgconfig or it doesn't, and the user may or may not need (or want) to rely on pkgconfig to add custom include paths. I don't think the platform used enters into the equation. But if pkgconfig is by definition NOT available on a given target platform the corresponding code can be omitted from the build.
It's relevant to know here if KDevelop can be built without pkgconfig. If not, pkgconfig is by definition available for all platforms where the IDE can run.

May be we need to export some new interface from 'custom-definesandincludes' to allow for other plugins to put addiional sub-pages into 'Language support' page.

That probably requires more of an overhaul than anyone feels like implementing...

Pkgconfig available at Windows and Mac, but not installed by default and have no a standart place. On Windows pkgconfig may be in MinGW or Cygwin installations, on Mac in macports or in homebrew for example. It's depends from user configuration and wishes. So this functionality is optional and high specialized, but functionality of common-definesandincludes is common and generic. In most cases user cannot disable common-definesandincludes because it's a dependency for cmakebuilder, makebuilder and some other significant plugins.

Again, I strongly doubt that you can build kdevelop and all of its dependencies without having pkgconfig installed. Someone using kdevelop for development with libraries that provide .pc files will almost certainly have pkgconfig installed too. So really, the platform argument is moot IMHO. But if you really want to push it: as a Mac user I can guarantee that we (as in developers working on Mac) will have pkgconfig installed through one of a handful of package managers which we'll also be using to install the libraries we need for our development. IOW, pkgconfig *will* be installed in a more-or-less standard location (certainly considered standard on the local set-up) and you can bet it's on the path. Having used cygwin extensively in the past I am certain pkgconfig will be on the path in that universe too, and in the end that's all that counts (if you cannot configure the location of the executable).

And either way, your plugin only has a runtime dependency on the pkconfig executable, right?

It's right. Seems we talk about the same thing. Summary:

• Plugin don't need in #ifdef to compile-time disabling, because...
• Plugin available and can be used at all platforms.
• Path to pkgconfig executable and environment vars are configurable from kdevelop settings menu.

I think that this functionality should be optional, and merging it with pure generic plugin is wrong. User should to have ability to disable special/unusual functionality. It's my humble opinion.

Seems we need to call to other project members to listen them thoughts.

Yes, I'm hoping that others will chime in here on this aspect too.

I think that this functionality should be optional

AFAIC it's enough that use of the functionality is optional (which it is, just like the rest of the customdefinesand* plugin).
Consider that by default all plugins are loaded, so a new plugin will show up in the project config dialog's sidebar and you have to open another dialog to disable the plugin if you don't want it. (And then you never really know in my experience how plugin selection carries over to other and/or new sessions). OTOH, if you just add a page to the customdefines plugin, e.g. as a "pkgconfig" tab between the "Defines" and the "C/C++ Parser" tabs that has much less chance of getting in anyone's way (horizontal screen space is always less at a premium than vertical space) while still being visible enough and IMHO in a logical location.

Bonus: no need to worry about what icon to use ;)

Shouldn't these come from the project manager?

Shouldn't these come from the project manager?

Ideally yes (and I too feel it's a bit overkill to add another plugin to provide this functionality. But I agree with the author that this isn't always the case in practice (and never with the generic project managers).

Could be different if the skeleton project manager all other managers derive from had support for compilation databases but that's a different horse to flog.