include install path

[Aleix Pol]

On Wed, Jan 6, 2016 at 12:07 PM, René J.V. <rjvbertin at gmail.com> wrote:
> Hi,
>
> Mostly out of curiosity:
>
> With KDE4, it was possible to build KDELibs with -DINCLUDE_INSTALL_DIR (say, ${prefix}/include/KDE4), and this setting would be stored in one of KDELibs' cmake modules so that all dependent software knew where to find the headers, but also installed its own header files under the same path.
>
> This has proved to be very valuable to me to prevent header conflicts/confusion when building KF5 applications for a prefix that is not entirely different.
>
> While the KF5 Frameworks are well-behaved in this aspect, KDE5 as a whole seem to have dropped this feature of defining a global header "prefix". The Frameworks headers end up in ${prefix}/include/KF5, but most if not all others under ${prefix}/include . I haven't tried this, but I have good reason to believe that this will lead to problems building KDE4 for  whatever prefix if KF5 is installed into /usr ; in my experience it is near impossible to prevent the compiler from finding headers in a default search location like /usr/include or /usr/local/include even when trying to do a build for a prefix that should be independent (like /opt/local).
>
> Is there a specific reason why there is no more "global" support for a dedicated header install prefix, or have I simply missed it because it is now available in some other way?

As somebody said this is not really on topic, but I'll answer since
you took the time to write the e-mail.

It was done like that because:
- kdelibs4 and kf5 need to be co-installable.
- we want that a project needs to purposely link to a module to be
able to include it.

On the other hand -DINCLUDE_INSTALL_DIR was never meant to be done and
leads people to use cmake weirdly instead of fixing upstream.

Aleix