Hi, moving the discussion from kde-core-devel to the more appropriate place, I guess :)
For those who did not follow there: We have been discussing the problem that internal classes are not visible outside of libraries if using visibility masks, so linking the libraries to tests for those classes does not work anymore. Am Donnerstag, 11. Mai 2006 00:14, schrieb David Faure: > On Wednesday 10 May 2006 21:44, Thiago Macieira wrote: > > Maybe our debug build could do like that: no symbol hiding. > > And then all the developers using debug builds would keep making > visibility-related mistakes. Not a good idea IMHO. Hm, true. This also applies to the troll solution, Simon told us about, using Q_INTERNAL_EXPORT macro and doing special test builds. And it hurts testing, if one has to do an extra step with switching between internal and external builds. :/ > I think we should just use convenience libs (but I'm not sure if cmake > supports that since we didn't need this up to now) or to link the .o files > into the test programs. I agree with Frans here, convenience libs are more convenient, not only by name ;) and that's needed for testing. Linking the .o files manually might make sense if the tests should also test for dependencies. But don't most people check for this already in the normal build? At least I do by separating coupled code in separate (convenience) libraries and linking those explicitly to needed libs, checking for unsolved symbols... oh, I think I have done, but I do not find any examples right now... thinking and working in separate worlds, again? :| Can one check static libraries for unresolved symbols, and is this portable? So given the restrictions Thiago teached me I see two solutions, perhaps both are needed/usable: a) Building a separate static library next to the dynamic one b) Buidling a separate dynamic library with visibility masking turned off, postfixed *_test or something, only used by tests Solution a) would be the convenient case for linking in the .o files, for basic classes with no further dependencies on other libs or for controlling the other linked libraries in the test build. Solution b) would be even more convenient for those tests where one doesn't (want to) care about dependencies on other libs for each test, but define them in one place (linking of the separate dynamic lib) and be done. Alex, William, any other cmake guru, please: (How) could we build static libraries? (How) could we build separate libraries with some build flag (visibility here) turned off? (How) could/should we link to uninstalled libraries (very much appreciated)? What false assumptions did I make again? <:) Are there any plans to "make test/check" trigger a test build like with auto*? Does this all make sense? Regards Friedrich
pgpn1RdGtyY4O.pgp
Description: PGP signature
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
