> 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