building KF5 projects against a different Qt5 version (than the one the KF5 frameworks were built against)

[René J.V. Bertin]

On Sunday April 26 2020 18:19:28 David Faure wrote:

>> The possibility to use precompiled headers is only an argument here when
>> increased compilation times are brought up as an argument against such a
>> header. But that's not really an argument if you can continue to use just
>> the headers you need. 
>
>Well, then you never need all-inclusive headers.

Who was talking about a hard need?! Convenience isn't need...

And as to precompiled headers: have you already used them? You need *an* all-inclusive header, but AFAIK you can only have a single precompiled entity, which typically means that you create such a header beast for your project, in which you include every header that can be included from as many of your source files as possible. So we're back to the convenience argument: you could keep it selective for minimum build overhead (and maybe a little less dead code if your linker isn't too good at stripping that), or you can keep it short and include that hypothetic single header per framework.

>> I could just as well maintain that nobody needs any of that particular
>> framework ;) 
>
>OK now you make no sense at all anymore, since I can give you 500 proofs of 
>the contrary: actual pieces of code that use some parts of KCoreAddons, and 
>none of them which use all of it.

I was referring to code that just rolls their own implementation of the code in almost an given library. It's a bit of a pathological argument but I'd say it's beyond argument that you can always do that, whereas even exhaustive knowledge of all existing code that uses that particular library (and only part of it) constitutes no proof that no code could every need all of it.
In fact, all one has to do to reject your hypothesis is write a single application that contains an exhaustive set of unit tests of all of the library's APIs. In fact, just unit tests of the ctors would do for most libraries/frameworks.

>And then people commit code that uses "everything", slowing down compilation 
>times. We don't accept it in KF5 code (nor in most of KDE apps/workspace 
>AFAIK), I don't see why we should provide something that we forbid.

That's another argument, but one that ought to be backed up with actual measurements of that slowdown. And: aren't KF5 frameworks supposed to be appeal as universally interesting sets of additions to Qt, outside of actual KDE apps (which I thought didn't exist anymore after KDE4 O:-) )? Providing something doesn't mean you have to accept its use under all conditions (Qt's private APIs come to mind as a relevant example).

>-Werror=undef is your friend.

That'd be the 1st time a -Werror is actually a friend, but I see your point.

R