Am 13.09.2012 um 10:19 schrieb Stephen Kelly <stephen.ke...@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.ke...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
