> On Sept. 19, 2014, 10:24 nachm., Martin Gräßlin wrote: > > overall I rather tend to -1 for these changes. I consider changing the > > build system in a long term release as way too risky considering that the > > core development doesn't use this iteration any more. Any unintended > > breakage (e.g. a component also not being built on X11) would probably not > > be spotted and that's something we certainly don't want to do in a minor > > version. > > > > Given that we are already in a late state of the bug fix only development > > it should not be difficult to keep the patch downstream as a > > distro-specific patch. > > René J.V. Bertin wrote: > That's re: the changes to the CMakefile? I frankly don't see the risk. I > took care to piggyback most changes to those files on WIN32 conditionals, and > there are no APPLEs running Qt/X11 that could run this kde-workspace versin. > But checking for false positives on Linux is easy enough (I can try to do > that over the weekend). Besides, core development may not be using "this > iteration" anymore, but that doesn't mean no one else would spot a > hypothetical regression... > > Ben Cooksley wrote: > Martin, can you please clarify how changing an if( NOT WIN32 ) to if( NOT > WIN32 AND NOT APPLE ) would make a difference to platforms which are not > Windows or Apple based? > > We've been trying to encourage upstreaming of patches from both the > Windows and Mac builds to make it easier to build these directly from source. > This is particularly crucial with Plasma Next / KF5 / etc.
> can you please clarify how changing an if( NOT WIN32 ) to if( NOT WIN32 AND > NOT APPLE ) would make a difference to platforms which are not Windows or > Apple based? which it isn't. There are also changes in the structure with now more if-else. To me each of them is a risky change as the whole thing is no longer tested. Personally I always weight the risk of regression against the probably gain for each patch going into the stable branch. For our main platforms in this case there is no gain, only the risk for regression. So with my Linux developer hat on, I don't like the idea of it being touched. Also I do not understand why one would want kde-workspace on MacOS. With Windows maintainers we just concluded that it doesn't make sense to offer it and the new split repositories don't support building for Windows any more. Given that I just fail to see what would be the gain of having kde-workspace being built on MacOS or what advantages this would give to users on said platform. E.g. there is now the launch KCM being built on MacOS. Who will benefit by that? It's a KCM to configure the behavior of X11 startup notifications. The settings are read by KRunner, the taskmanager and KWin. All three are excluded from building, though. Fonts KCM is not being built, but fontinstall is. Again it probably will build, but it's completely useless - I have seen the X11 dependency of it when trying to use it on Wayland. krdb is being built, although it's so X11 specific that there is now a huge #ifdef Q_WS_X11. While I appreciate the work on making our software work on more systems, I highly doubt there is need in making the LTS kde-workspace module build on MacOS. I think it would be better to look at the now split repositories and provide those which make sense without needing to introduce risky changes. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120287/#review66990 ----------------------------------------------------------- On Sept. 20, 2014, 12:05 vorm., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120287/ > ----------------------------------------------------------- > > (Updated Sept. 20, 2014, 12:05 vorm.) > > > Review request for KDE Software on Mac OS X and kde-workspace. > > > Repository: kde-workspace > > > Description > ------- > > A few rather straightforward patches to make the relevant bits of KDE4's > kde-workspace build and function on OS X. > The main interest is having the systemsettings control panel to control the > various relevant KDE settings among which desktop search, fonts, colours and > even style. > The oxygen style builds and looks good but shows some updating glitches due > to compositing. > > I'm submitting this patch partly in hope it may be useful in bringing > kf5-workspace to OS X, one day. > > > Diffs > ----- > > CMakeLists.txt 195f99c > kcontrol/CMakeLists.txt fc666b1 > kcontrol/krdb/krdb.cpp 36fc99c > kcontrol/style/CMakeLists.txt d832b20 > libs/CMakeLists.txt c0576fe > > Diff: https://git.reviewboard.kde.org/r/120287/diff/ > > > Testing > ------- > > On OS X 10.6.8 and 10.9.4 with KDE/MacPorts (4.12.5 and more recently kdelibs > git/master, 4.14.1). > > > Thanks, > > René J.V. Bertin > >
