That could be useful for project managers that lack proper build system integration (IOW, there shouldn't be much use for it with the CMake and QMake project managers?)

Maybe this pkgconfig plugin shouldn't be shown in projects that don't need it, or else maybe the UI could be added to the language support page? That's what it applies to after all, no? I'd vote for keeping the list in the left side-bar as short as possible.

This plugin may be useful for any c/c++ project. For example indexer for CMake project KDevelop (sources of ide) don't see all required includes for me. I've added paths to includes of QT, KDE and some other manually. And it was much easier than trying to fix automation.

And i see in left-side bar Clang-tidy, Clazy, Cppcheck which also may be useful for any c/c++ project. But i not use them for now.

So, i think we need to allow for user do decide which additional tools to use in him/her project. But i don't know how to organize that.

Also "Language support" page provided by plugin named 'custom-definesandincludes'. I cannot to integrate panels from one plugin to another plugin. I can only insert all of my code into 'custom-definesandincludes' plugin - it is seems wrong. But would be glad to use some common functionality for appling and store per-file or per-folder configurations which implemented inside of 'custom-definesandincludes', but not ready to export to common use from other modules. For now i just replicate similar functionality of 'custom-definesandincludes' in my plugin - it's not ideal solution.

This plugin may be useful for any c/c++ project. For example indexer for CMake project KDevelop (sources of ide) don't see all required includes for me.

After a full build? A priori that's a bug, possible related to use of the CMake server or how you set up your build directory.

And i see in left-side bar Clang-tidy, Clazy, Cppcheck which also may be useful for any c/c++ project. But i not use them for now.

Yes, there is already a considerable list of entries in there (and yes, the clazy and cppcheck could share the same tab because they provide comparable functionality).

Also "Language support" page provided by plugin named 'custom-definesandincludes'.

You'll get more feedback on this when you present your patch via a differential (aka "patch") review.
Is there any reason why you do not simply add the pkgconfig interface to that plugin? After all it just provides another way to add required defines and/or includes, no?

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 to this page :)

'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. So, seems, it's not a pure plugin but a significant part of platform. 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.

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.