> On Feb. 8, 2014, 10:07 a.m., David Faure wrote:
> > Urgh, we were hoping this wouldn't be an issue.
> >
> > This commit would break #include <attica/event.h>, so it cannot go in.
> >
> > All "namespaced" frameworks do it this way already btw, see kparts for
> > instance:
> >
> > -- Up-to-date:
> > /d/kde/inst/kde_frameworks/include/KF5/KParts/KParts/ReadWritePart
> > -- Up-to-date:
> > /d/kde/inst/kde_frameworks/include/KF5/KParts/kparts/readwritepart.h
> >
> > Since there is no filename clash, what is the issue if these end up in the
> > same folder on Mac OSX?
>
> Harald Fernengel wrote:
> Here's the layout after "make install" on OS X:
>
> include/KF5/KParts/textextension.h contains:
>
> #include "/tmp/kf5-kparts-ty2Y/src/textextension.h"
>
> ^^^ this is broken, points to the temporary build dir...? What should
> this include?
>
> Then, we have include/KF5/KParts/KParts/ which contains both lower case
> and upper case headers.
>
> include/KF5/KParts/KParts/textextension.h is the actual header
>
> include/KF5/KParts/KParts/TextExtension contains:
>
> #include "kparts/textextension.h"
>
>
Ah, I see. The local forwarding includes which are supposed to only be used
during compilation of kparts, get installed because they end up in KParts/
instead of kparts/ (and the cmakelists.txt file just installs the whole
directory).
I can think of two solutions...
1) put local forwarders into ./local/kparts instead of ./kparts, to ensure they
stay out of ./KParts
2) change cmakelists.txt to install a list of camelcase headers instead of just
"the whole directory" (which gives surprises with an unclean builddir,
installing old stuff still lying around)
The first one seems simpler.
In kparts/src:
- target_include_directories(KF5Parts PUBLIC
"$<BUILD_INTERFACE:${KParts_BINARY_DIR}>")
+ target_include_directories(KF5Parts PUBLIC
"$<BUILD_INTERFACE:${KParts_BINARY_DIR}/local>")
And in CEM:
diff --git a/modules/ECMGenerateHeaders.cmake b/modules/ECMGenerateHeaders.cmake
index e98a22e..38839f2 100644
--- a/modules/ECMGenerateHeaders.cmake
+++ b/modules/ECMGenerateHeaders.cmake
@@ -50,7 +50,7 @@ function(ECM_GENERATE_HEADERS)
endif()
if(NOT EGH_OUTPUT_DIR)
- set(EGH_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR})
+ set(EGH_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR}/local)
endif()
# Make sure EGH_RELATIVE is /-terminated when it's not empty
Can you try it?
- David
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115541/#review49240
-----------------------------------------------------------
On Feb. 7, 2014, 7:37 p.m., Harald Fernengel wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115541/
> -----------------------------------------------------------
>
> (Updated Feb. 7, 2014, 7:37 p.m.)
>
>
> Review request for KDE Frameworks.
>
>
> Repository: attica
>
>
> Description
> -------
>
> Case-insensitive filesystems don't like the Attica vs. attica pathes, when
> installing, the headers would all be messed up. Instead, install everything
> to include/KF5/Attica to be in line with the other frameworks.
>
> Note - this might not be the best solution, but we need one in order to
> deploy on Mac OS X :)
>
>
> Diffs
> -----
>
> src/CMakeLists.txt 676c8a8e78420371bba19414b3f090180a49758d
>
> Diff: https://git.reviewboard.kde.org/r/115541/diff/
>
>
> Testing
> -------
>
> Only on Mac OS X
>
>
> Thanks,
>
> Harald Fernengel
>
>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
