Testing file offset bits?

[Alexander Neundorf]

On Monday 22 April 2013, Stephen Kelly wrote:
> On 04/22/2013 08:46 PM, Alexander Neundorf wrote:
> > On Monday 22 April 2013, Stephen Kelly wrote:
> >> Users of kdelibs will be using either Qt file APIs or something from
> >> kde_file.h, which will still use the definition.
> >> 
> >> If we use our imagination, we could say that potentially someone could
> >> be using open directly and relying on the definition having been set
> >> elsewhere. That would not be smart on their part, is vanishingly rare
> >> (because obviously they'd use Qt APIs instead), and I don't think we
> >> should care.
> > 
> > We are not talking about building kdelibs or even KDE SC here, we are
> > talking about everything out there building against kdelibs.
> 
> Yes, exactly. My comment above should be read with that in mind.
> 
> > They all get those 64-bit-related definitions with KDE4, and I think they
> > also got them with KDE3 and maybe also KDE2.
> 
> Even if it has been there for a long time, that doesn't make it a good
> idea.
> 
> Anyway, any 3rd party code which uses kde_file.h will still get the
> definition, even if they don't use KDE_open, and use open directly instead.
> 
> > Nobody is forced to use KDECompilerSettings.cmake anymore with KDE
> > frameworks. This file contains optional compiler settings, which are
> > considered useful. If a developer wants to take care of this himself, he
> > simply does not have to use that file.
> 
> Right. However, note that my solution of putting the define in the
> INTERFACE_COMPILE_DEFINITIONS of kdecore (or whatever target kde_file.h
> ends up in) takes the choice out of the 3rd parties hands. Even if they
> don't use KDECompilerSettings.cmake, they still get the define, so my
> solution is probably 'more safe' from that point of view.
> 
> > Why break apps which may rely on those flags being present and force them
> > to take care of this themselves, probably only after some user reported
> > breakage on large files after upgrading ?
> 
> That would be the case if KDECompilerSettings.cmake is not used, and it
> would be the case if kdecore is not used.
> 
> I don't think it is a general responsibility of KDE to provide compiler
> flags to projects which are unaware of them anyway, and are doing their
> own thing anyway (by using posix open directly, going against the
> documentation of both QFile and kde_file.h).

There are two issues here:
This change potentially breaks some applications, and not an in obvious way.
This is bad in itself. We should only do that (should we actually ever do that 
?) if there is a really good reason for it.
I don't see any.
What problems does keeping those defines create ?

And the second one is, that yes, it is responsibility of "KDE" to make the 
life of KDE developers easier, by providing sets of flags and settings which 
make development in some way easier.
Have a look at KDECMakeSettings.cmake, KDECompilerSettings.cmake and maybe 
also KDEInstallDirs.cmake.
There is not much (is there anything at all ?) in those files which is 
required to build an application which uses some KDE libraries.
Nobody has to use them, everybody can perfectly build his own application just 
using the Config.cmake files created by the frameworks libraries, they contain 
all the *necessary* information.

The purpose of those three files is to make life for (lazy ?) developers 
easier, so they don't have to care much about cmake or RPATH or compiler 
settings, but simply get a recommended set of flags which should make 
everything work as expected.

Nobody really needs the following lines to build a KDE application:
if (... GNU)
  ...
  set(CMAKE_CXX_FLAGS_DEBUG  "-g -O2 -fno-reorder-blocks -fno-schedule-insns -
fno-inline")
   ...

This is all just convenience.

I'm very much for reverting that change.

 
> Particularly as we're creating a 'breaking release' (KF5), and generally

I thought the goal is to keep breakage and porting work as low as possible.
As I said above, I don't think we need to add breakage which is not necessary.

> making our code more appropriate for ourselves, I don't think we need to
> be concerned with non-conformant use of KDE4 libs and I don't think we

I am not aware of what "non-conformat use of KDE libs" is.
Using open() is perfectly fine in my opinion, not everybody is writing cross-
platform software.

> need to be concerned with imagined expectations for compiler flags an
> imagined 3rd party relies on.

I don't think there is a lot of imagination involved in assuming somebody uses 
open().
 
> > You may say that direct usage of open() etc. is considered bad in kdelibs
> > or KDE SC, but it is valid POSIX API, and any 3rd party developer is
> > free to use it and I'm far from saying that it is per se a bad thing.
> 
> kde_file.h says that its open() is a replacement, so it should be used
> instead of the direct open().
> 
> My opinion is that we should confine defines to where we know they are
> required (as I did in my commit), 

As I said above, not much in those three files is "required", then we could 
remove them completely.
I don't think KDE developers would be happy about that.

Alex