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

[Stephen Kelly]

On Thursday, September 13, 2012 13:56:33 Till Oliver Knoll wrote:
> Am 13.09.2012 um 10:19 schrieb Stephen Kelly <stephen.kelly at kdab.com>:
> > ...
> > 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.
> 
> Okay, I get your point there: however I still don't consider those points as
> bad in my situation, because
> 
> - I never do static libraries

In the future you might. "Always be prepared".

> - I hardly ever #include dependencies in *headers* (only if there's no other
> way, as outlined previously), so it is extremely unlikely that there will
> be a stray #include after some refactoring - Yes, I worked in (small, but
> highly disclipined) teams like that in the past 10+ years like that and the
> scenario you described never - ever - occured. 

That doesn't make it a good idea. Having an entire team so highly disciplined 
is rare, but I don't think even that solves the problem. There are stray 
includes in Qt. Mistakes happen. In reviews, people look at a patch, not 
whether an include at the top of the file can/should be removed.

Refactoring can cause mistakes like this even in highly disciplined teams. In 
your case a stray include from which nothing requires linking would require 
humans who have better things to do than make up for lack of tool support to 
catch errors like this.

Additionally:

* You don't know who will maintain the code in 5/10 years. Maybe your company 
will be bought by $BIG_CORPO_WITH_CRAPPY_DEV_METHODS
* From a consultant point of view, I'm sometimes working with other peoples 
code. No matter how disciplined I am, I can't expect that every team I visit 
is going to keep track of includes with human methods as carefully as is 
required without the tooling help.

> So doing "module includes"
> worked for us - I agree that on Linux by default you might not catch such
> an "undefined symbol" when compiling a shared library, but on Windows and
> Mac you do 

You never know when a codebase will be ported to another OS. 

Addtionally - The stray include in a public header problem *does* happen on 
Windows/Mac.

As a reminder, in case it's still not clear, I'm talking about two orthogonal 
issues that you expose yourself too.

1) Stray, forgotten includes which cause your downstreams to have headers 
installed which are not used.
2) Substituting compiler errors for linking errors.

> - so no, in my case it cannot happen that you "only notice it
> way later downstreams" when trying to link to that library
> 
> So yes, I agree with you that in a very large project such stray #includes
> might lead to confusion. But my point is that it works for me 

By the same logic, turning off all compiler warnings is 'not a bad idea per 
se'. 

A highly disciplined team can simply see code that causes undefined behaviour 
as they write it and correct themselves, right?

> and I
> disagree with the statement in general that "module imports" are bad per
> se,

I maintain that they are a bad idea. This is just friendly advice that I'm 
broadcasting and justifying. You can do what you want :).

> because they help *me* to better organise my includes 

That 'organization requirement' is a side effect of using module includes.

You want 

#include <QtCore/QFile>
#include <QtCore/QObject>

#include <QtGui/QFont>

instead of 

#include <QtCore/QFile>
#include <QtGui/QFont>
#include <QtCore/QObject>

right? I don't think that adds quality over 

#include <QFile>
#include <QFont>
#include <QObject>

or 

// QtCore
#include <QFile>
#include <QObject>

// QtGui
#include <QFont>

or any other variation (including non-sorted), especially considering the cost 
of preventing the tooling from informing you of the problems.

> and avoid having
> wrong dependencies in the first place.

... by relying on humans getting it right every time (not just once!) instead 
of having tooling catch it every time.

> > 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.
> 
> So we have a common agreement that in both cases the tools tell us that
> something is wrong.

Not in the case of a stray unused forgotten include. You have no tooling 
telling you about that. 

You just rely on humans always realizing it as they are typing/refactoring 
even if they're thinking more about the urgent deadline next Wednesday-week 
instead of thinking about the includes at the top of a several hundered line 
file.

> So your previous statement that I "disable the tools"
> is not quite correct: in my case it is just the linker telling me that I
> should have linked to something, instead of the compiler.

1) Not in the case of a stray unused forgotten include. 
2) That's suboptimal.

> > You've
> > just wasted all that time (and now you get to spend time tracking down the
> > root cause - I've already fixed it).
> 
> Just the link time can be considered wasted!

Try building webkit or llvm/clang some time :). 

Consider a library with several hundred cpp files all of which are several 
thousand lines of code. Consider a stray include in the first one. I get the 
error notification immediately. You compile all other objects and get a link-
time error much later.

> So I wasted a little bit more time than you, I had to relink. But for me the
> advantages to have the #includes properly organised and the dependencies
> made explicit outweighs that disadvantage.

'Organized' as above? 

Your buildsystem makes the dependencies explicit anyway.

> Because hey, 95% I spend coding,
> and the rest setting up the *.pro files (in fact I copy/paste them these
> days from previous project), so it's not like every day you encounter such
> "mysterious linking errors". ;)

Not if you only work on small projects with small teams.

Anyway, my advice is: Don't use module includes.

Take it or leave 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/195a26c8/attachment.sig>