Alexander Neundorf wrote: > On Saturday 16 February 2013, Stephen Kelly wrote: >> Alexander Neundorf wrote: >> > On Saturday 16 February 2013, Stephen Kelly wrote: >> >> Hi Alex, >> >> >> >> -some compiler flags tweaking >> >> >> >> -reenable the test for visibility in Qt >> >> -reenable the test for FILE_OFFSET_BITS=64 (... there may be maybe >> >> some >> >> >> >> embedded systems where this is not the case ?) >> >> >> >> >> >> Do you have any reason to think this is needed? The maybe is pretty >> >> strong in this sentence :). >> > >> > First, there was probably a reason why this check was added, so just to >> > be sure I enabled it again (it has always been enabled in >> > FindKDE4Internal.cmake), it was only disabled in e-c-m. >> >> I don't think adding code we don't understand to ecm is a good idea :). >> People have added things mistakenly, and people have added things for >> platforms where Qt 5 does not work. >> >> Let's not try to 'maintain' things we do not understand. >> >> Let's simplify and remove instead. In many cases, the correct place to >> fix things is in cmake. One of the whole motivations behind KDE >> Frameworks is to simplify or code, to rely on upstreams(primarily Qt and >> CMake), and to fix upstreams where necessary - not workaround them. > > Dirk Mueller added it in 2008: > http://websvn.kde.org/?view=revision&revision=829068 > > If I remove every compiler flag where I'm not sure why it is needed, we'll > be left with not much.
Being not left with much would be a good thing, not a bad thing. It would be an effect of not supporting ancient compilers, and an effect of CMake providing better abstraction. > > That's basically how I started in 2006, with minimal compiler flags. > Then over time issues appeared, and the flags were added for a reason. To be useful, the reason needs to be recorded. If the reason for things is recorded as 'workaround bug in GCC 2.95' or 'needed for MSVC < 2010', then we can remove it. As the reason is not well recorded in every case, the issue currently under discussion comes up. > > I don't see why we should remove them now again and start over with adding > them when we hit the same problem again. Here I have to disagree. One reason for that is because some of them are out of date due to expired compilers or newer CMake features. Another reason is that the world has changed a bit. Now, more than in 2006, we're working upstream more. If something is needed because of a quirk in Qt or CMake, we're more likely to be able to fix that. > So if you find out why it was necessary in 2008 and why it is now not > necessary anymore, I'm all for removing it. But otherwise we should keep > it. Disagreed. :) I see no reason to carry lines of code we don't know we need or lines we know we don't understand. I do agree with doing research to find out why the things exist, and if they have a good reason to exist, keeping them and recording the reason properly. Please take that approach with the rest. I'll email Dirk. Thanks, Steve. _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
