kde_file.h vs POSIX headers vs qplatformdefs.h

[Aurélien Gâteau]

Le jeudi 8 août 2013 18:27:00 Kevin Ottens a écrit :
> Hello,
> 
> On Thursday 08 August 2013 16:56:23 Aurélien Gâteau wrote:
> > I started working on a kdelibs cleanup task:
> > 
> > "Make use of qplatformdefs.h definitions instead of using the POSIX
> > versions directly. Partly revert that commit, that would port to
> > QFile::Permissions: b03e81a61311ae1b64b0d37415477f9c08fe6142"
> > 
> > I have a few questions however:
> > 
> > 1. I am not exactly sure what "partly revert that commit" means.
> 
> I think you'll need David to answer that one.

OK, will wait for David then.
 
> > 2. I filed a first request replacing all calls to fopen() and *stat() with
> > their qplatformdefs.h equivalents (QT_FOPEN and QT_*STAT) [1]. I am
> > worried
> > however that this effort is going to conflict with the "port away from
> > kde_file.h" tasks. Should this task be merged with the kde_file.h tasks
> > instead? And should we ensure ports from kde_file.h uses the qplatformdefs
> > functions instead of the POSIX ones?
> 
> I've been thinking the same *but* for the reviews we so far pushed back the
> introduction of POSIX calls and instead asked for either QT_* or use of
> QFile/QFileInfo.
> 
> In fact that's more my worry with the current introductions of
> qplatformdefs.h... Maybe we'd be better off using QFile/QFileInfo in most
> case and use qplatformdefs.h only when there's no other choice. It's more
> porting work though...

Porting to QFile/QFileInfo is more readable, but there are higher chances of 
breakage when doing the kind of "brute-force" porting I started. I think it 
should be up to the module maintainer to do such port since he/she can test 
it.

Actually, I am wondering if porting to qplatformdefs is the highest priority: 
the fact we are using POSIX functions right now does not prevent splitting, 
does it?

Aurélien