[Interest] My experience porting to Qt5 (on OS X)
Stephen Kelly
stephen.kelly at kdab.com
Thu Sep 13 10:19:34 CEST 2012
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>
More information about the Interest
mailing list