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

[Joseph Crowell]

On 9/14/2012 1:11 AM, Stephen Kelly wrote:
> 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.

While reading this thread, something occurred to me. Would it be 
possible to add detection of unused includes to Qt Creator similar to 
detection of unused variables?

>> 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,
>
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120917/57e12870/attachment.html>