Review Request 115541: Build fix for Mac OS X

[David Faure]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140209/3a77cbae/attachment.html>