Review Request 125083: Move X11 related find_package under X11_FOUND

Samuel Gaist samuel.gaist at edeltech.ch
Fri Sep 11 15:10:19 UTC 2015



> On Sept. 7, 2015, 7:17 a.m., Martin Gräßlin wrote:
> > hey OSX-devs: we need to find a better solution for this things. I didn't notice the review before it was pushed, but I would not have given a shipit for it.
> > 
> > The solution is sementically wrong. We are now binding finding XCB to whehter XLib is found. In the long termn XLib support will become a deprecated feature, maybe even completely removed in KWindowSystem. Most is already ported to XCB. What then? We go back to finding XCB and it will be found again? Then there is nothing to group with.
> > 
> > Please think about a long term strategy how you want to handle the X11 dependencies. We have had many such reviews lately and it's always a local "workaround"/"fixup" to some OSX build-oddities. Please have a look at the bigger picture and think about a general solution on how to disable X11 without having to (stupidly) patch all frameworks.
> 
> Samuel Gaist wrote:
>     Hi,
>     
>     Sorry for that mistake.
>     
>     What about providing KF5 X11/XCB specifc cmake search modules ? This will also require patching of the frameworks but will allow to disable it globally when needed ?
> 
> Martin Gräßlin wrote:
>     > allow to disable it globally when needed ?
>     
>     But that's already built into CMake. Just pass the right flag at command line and it will build without X11/XLib support. Our CI system does that for every build. Given that I don't understand why OSX devs want again and again (you're not the first and probably not the last) add specific solutions to their system because somehow X11 ends in the build.
> 
> Samuel Gaist wrote:
>     To avoid repeating that in the future (and even clean the current state), can you share the correct flags to use before starting a build ? I may have miss them while searching information for kdesrc-build. 
>     
>     X11 can easily end up in the build because of some unrelated packages pulling it as a dependency when using e.g. macports.
> 
> Martin Gräßlin wrote:
>     From our CI system:
>     cmake -DCMAKE_DISABLE_FIND_PACKAGE_X11=TRUE
>     
>     and so on. It's a standard cmake feature. A general solution would btw be to add that into ECM so that it automatically gets applied for all framework builds.

I've proposed it here: https://git.reviewboard.kde.org/r/125163/

What do you think about cleaning the KDE various projects for X11 XCB related stuff ?
For this one we could replace the original if(NOT APPLE) by NOT WIN32 and move the XCB finding back to its original place.


- Samuel


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125083/#review84937
-----------------------------------------------------------


On Sept. 7, 2015, 7:25 a.m., Samuel Gaist wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125083/
> -----------------------------------------------------------
> 
> (Updated Sept. 7, 2015, 7:25 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> -------
> 
> This avoids trying to detect X11 packages that might be installed on OS X
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 3460224eb895b2295b6e7ee66dd8258da5ec2b91 
> 
> Diff: https://git.reviewboard.kde.org/r/125083/diff/
> 
> 
> Testing
> -------
> 
> Build on OS X 10.8
> 
> 
> Thanks,
> 
> Samuel Gaist
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150911/79d7cc5f/attachment-0001.html>


More information about the Kde-frameworks-devel mailing list