Feature request - Incremental defines and includes configuration
Open, Needs TriagePublic

Description

For now we need to copy most part of includes to each configured folder.
You may see it at this struct of example project:

`
folder            # includes
----------------------------------------------                  
myproject
 - libmyproject   # common
 - modules
 - - a            # common, libmyproject, third-party libA
 - - b            # common, libmyproject, third-party libB
 - cli-tool       # common, libmyproject
 - application
 - - actions      # common, libmyproject, third-party libUiModel, libUiActions
 - - gui          # common, libmyproject, actions, third-party libUiModel, libUiActions, libUiWidgets
`

I suggest to implement functinality where child folder inherits includes and defines from parent, and configuration become much easier:

`
myproject         # common
 - libmyproject
 - modules        # libmyproject
 - - a            # third-party libA
 - - b            # third-party libB
 - cli-tool       # libmyproject
 - application    # libmyproject, third-party libUiModel, libUiActions
 - - actions
 - - gui          # actions, third-party libUiWidgets
`

To keep compatidility we may to add checkbox "inherit includes" to the includes (and defines) config page for project path.

To implement this i suggest the following interface in *IDefinesAndIncludesManager*. Function *apply* calls in order from parent to child directory.

`
class IDefinesAndIncludesManager {
public:
    ...
    class IncrementalProvider {
    public:
        virtual ~IncrementalProvider() = default;
        virtual void apply(Defines &defines, Path::List &includes, ProjectBaseItem* item) const = 0;
    };
    ...
    void registerIncrementalProvider(IncrementalProvider* provider);
    bool unregisterIncrementalProvider(IncrementalProvider* provider);
    ...
};
`

As continuing of discussions started in #T10209 and #D17794, for better integration i suggest to allow other plugins (pkgconfig for now) to extend UI of custom-definesandincludes page (it's named Language Support). I think the better solution is to implement such interface as used in IPlugin::perProjectConfigPage:

`
class IDefinesAndIncludesManager {
public:
    ...
    class UImanager {
    public:
        virtual ~UImanager() = default;
        virtual int perPathConfigPages() const;
        virtual ConfigPage* perPathConfigPage(int number, ProjectBaseItem* item, QWidget* parent);
    };
    ...
    void registerUImanager(UImanager *manager);
    bool unregisterUImanager(UImanager *manager);
    ...
};
`

Also significant part is to save per path configurations of plugins by the common method. Seems we need to implement base class for config page similar to *ProjectConfigPage*, named *ProjectPathConfigPage*. Which will provide methods to access KConfigGroup specified to current project path. But in this way we should to save configuration each time when user changed the path, with popup message about it, as like as switching of project config page in left bar.

What you think about it?