Testing file offset bits?

[Stephen Kelly]

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.