[Interest] My experience porting to Qt5 (on OS X)

[Stephen Kelly]

On Thursday, September 13, 2012 07:33:52 Till Oliver Knoll wrote:
> Well, that's /exactly/ my point ;) By doing "module includes" I instantly
> realise at the earliest possible stage, "at typing time" (as opposed to
> compile- or link time), that "Oops! That comes from QtWidgets! That
> shouldn't be here in my model".

Yes. You rely on yourself to add no includes by mistake. More broadly, if you 
work in a team, you rely on everybody adding no includes by mistake.

You're ensuring that the tool can not help you.

> Besides, even if I would want to #include it, that because I'm going to use
> it within that library

> (or why else would I include it?). 

By mistake. Include it but do not actually use anything from it. Forget to 
remove the include. The include is still there in your installed public 
header.

Do you think it doesn't happen? Look at this commit from a few months ago:

http://commits.kde.org/kdelibs/76d2701bb48848a6f39b4a1c9c4bdbf3a3b97e50

KConfigCore doesn't and never has linked to QtWidgets. Those includes were a 
bug and a mistake. Most likely they were there because KConfigCore was 
refactored out of a larger library which does link to QtWidgets.

> And if I would
> forget to say QT += widgets in "model.pro", I'd simply get a linker error.

Only if you attempt to use something from the header which requires linking.

Otherwise you will just have a stray include without using anything from it, 
but it will affect downstreams. I tried making that clear in my last mail, but 
your response indicates that you missed my point there.

> Agreed, in that case your "non module include" would have the (slight, IMHO)
> advantage that you already get informed at compile time. I get informed at
> link time.

Or you get informed when your downstream tells you about it.

My whole point is that you are making sure your tool can not tell you about 
problems like that. You are relying on humans not making a mistake which means 
you're already at a disadvantage. 

> 
> And I'm not sure what you meant by "mysterious linking error"

If you do attempt to use symbols from the library you get a linker error which 
in my experience can be harder to find the root cause of - it's only obvious 
if you already know the cause. Add to that the fact that unless you use the 
flag -Wl,--no-undefined you won't get the error when you build a static 
library, but only when you link the target that uses that static library. 
Mysterious.

Additionally if you have a large project to build then the linking failure 
might happen 30 minutes after the point where I get a compile failure. You've 
just wasted all that time (and now you get to spend time tracking down the 
root cause - I've already fixed it).

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120913/9d96edd5/attachment.sig>