> On March 20, 2015, 8:07 a.m., Martin Gräßlin wrote: > > as in other similar requests: -2 from my side > > Martin Gräßlin wrote: > To extend: I think the way is wrong. If it now builds on MacOS the > required is wrong. It should be an optional find_package properly ifdefed. > > Christoph Cullmann wrote: > Actually, you don't want that it is optional as you really don't want > that it ever is found on MacOS. If you install an XQuartz for legacy apps, it > will be found, and you will have a completly mess as result ;=) > > Martin Gräßlin wrote: > Christoph, that argument is wrong. The same would be the case with > Windows and any other platform which optionally offers X11 (this includes > Linux!). CMake can handle the situation quite well to disable an unwanted > build dependency. If a user installs XLib headers (which is not the same as > just installing XQuartz) we should expect the user to disable the cmake build > option. > > Christoph Cullmann wrote: > That means that nobody will get a senseful build on Mac, if he doesn't > disable that optional dependency. Thats the opposite of a normal optional > dependency, that leads to missing features if not found but not complete mess > if found. > I tried to compile frameworks stuff on Mac, and IMHO, really, that makes > it close to unusable, that you need to tweak each cmake call just to have > something usable, if you have too much stuff installed. I never had to do > that on Linux/Other Unices. > > Martin Gräßlin wrote: > > That means that nobody will get a senseful build on Mac > > What since when is XLib as a build dependency available by default on OS > X? > > Christoph Cullmann wrote: > Actually, if you work with Frameworks there, you will install something > over MacPorts or Homebrew, and yes, you will have XQuartz installed, to run > some legacy apps and there is really no user understandable way to install > XQuartz without its devel headers, the .dmg will just install everything, I > was suprised myself that I have X devel headers just by installing an > X-Server. My first workaround was just to deinstall XQuartz, later I started > to tweak CMake options or do exactly the same fixes as above. And yes, I > think, per default, without any magic options, frameworks should just build > to a usable state. And I see 0 reason to ever have even an optional "with > x11" build of an frameworks application. But I might be wrong. Therefore I > don't vote here or say ship it, just wanted to state my concerns ;=) > > Martin Gräßlin wrote: > my concern is that we make our CMakeLists.txt way more complex (it's not > the only framework which recently saw such a proposed change) and work around > broken systems in our CMakeLists. That's something I do not want to see - if > the downstream packaging sucks, it needs to be fixed there. We would tell the > same to every Linux distribution. > > I do not want to see such OS specific changes go in as X11 is not OS > specific - all operating systems we support in KDE can provide X11 and on all > OS there are alternative windowing systems. What I don't want to see is > something like: > if (NOT APPLE AND NOT WINDOWS AND NOT LINUX_ANDROID AND NOT > LINUX_UBUNTU_PHONE AND NOT LINUX_SAILFISH AND NOT LINUX_WEBOS AND NOT ... > > if we start with one platform, where do we end? Is adding the check for > Apple OK and Windows not? > > Christoph Cullmann wrote: > We could wrap the X11 search in a own module that will not do anything on > Apple, to avoid the if stuff. > On the other side, even with the if, it still avoids that we have some > combinations feasible in the frameworks, that we need will not test anyway, > e.g. apple + X11. > That avoids complexity, too. Actually I would be OK do have the same for > WIN, too, yeah, still better than a code path that you can configure in, that > actually will not work.
I'm not worried about the code paths - everything X11 specific should be runtime wrapped anyway in a if (QX11Info::isPlatformX11()). If not: that needs fixing. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/#review77779 ----------------------------------------------------------- On March 19, 2015, 11:59 p.m., Harald Fernengel wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/123075/ > ----------------------------------------------------------- > > (Updated March 19, 2015, 11:59 p.m.) > > > Review request for KDE Frameworks and Michael Palimaka. > > > Repository: kdesu > > > Description > ------- > > do not require X11 on Mac OS X > > > Diffs > ----- > > CMakeLists.txt 9623483d6f11f9cdb7d7dc19decfd7cf5e86d079 > > Diff: https://git.reviewboard.kde.org/r/123075/diff/ > > > Testing > ------- > > > Thanks, > > Harald Fernengel > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
