Fwd: How to build static libraries with cmake (and more)? (was: Re: Testing internal classes)

[Friedrich W. H. Kossebau]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20060511/e3eb9e8a/attachment.pgp