[Interest] My experience porting to Qt5 (on OS X)
stephen.kelly at kdab.com
Thu Sep 13 17:11:03 CEST 2012
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.
* 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
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
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
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.
right? I don't think that adds quality over
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
> 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 :).
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Interest