https://bugs.kde.org/show_bug.cgi?id=369554
David Faure <fa...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fa...@kde.org
--- Comment #2 from David Faure <fa...@kde.org> ---
Created attachment 118529
--> https://bugs.kde.org/attachment.cgi?id=118529&action=edit
Porting kpeople as an example
One solution would be to move the forwarding headers (the camelcase ones) to a
different directory.
So instead of
/opt/local/include/KF5/KPeople/KPeople/Widgets/Actions
/opt/local/include/KF5/KPeople/kpeople/widgets/actions.h
you'd have
/opt/local/include/KF5/KPeople/fwd/KPeople/Widgets/Actions
/opt/local/include/KF5/KPeople/kpeople/widgets/actions.h
Since cmake exports those paths as a target property, applications (using
cmake) wouldn't have to change anything.
Same for apps using the generated pkgconfig or .pri files.
See proof-of-concept patch for kpeople attached.
It would of course break any projects that make assumptions about the layout of
the include dirs (e.g. in hand-written Makefiles or something) instead of using
the cmake targets, but I can live with that, it's the reason to use a proper
buildsystem.
TODO: improving ECMGeneratePriFile.cmake and ECMGeneratePkgConfigFile.cmake to
support multiple include dirs as input.
--
You are receiving this mail because:
You are watching all bug changes.
