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

Till Oliver Knoll till.oliver.knoll at gmail.com
Thu Sep 13 13:56:33 CEST 2012


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
- 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. 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 - 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 and I disagree with the statement in general that "module imports" are bad per se, because they help *me* to better organise my includes and avoid having wrong dependencies in the first place.



> 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. 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.

> 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! Because the linker will tell me that the current library is missing some dependency - again, in my case it *can't* happen later on! - I *quickly* realise that "Oh, some QWidget related symbol not found - oh yes, that is now in 'widgets', I have to check the QT variable!", I fix the *.pro file, relink... done! No recompile necessary!

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. 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". ;)

Cheers,
  Oliver



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



More information about the Interest mailing list