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

[Friedrich W. H. Kossebau]

Hi Brad,

thanks for your answer.

Am Freitag, 12. Mai 2006 23:36, schrieb Brad King:
> Friedrich W. H. Kossebau wrote:
> > Alex, William, any other cmake guru, please:
> > (How) could we build static libraries?
>
> add_library(mylib-static STATIC src1.cxx src2.cxx)
>
> If you want it to have the same name as a shared library then set the
> OUTPUT_NAME:
>
> set_target_properties(mylib-static PROPERTIES OUTPUT_NAME mylib)
>
> This may have problems on windows though because the static mylib.lib
> will have the same name as the import library mylib.lib that goes with
> mylib.dll.

Different name is okay, but is there a possibility the libs could share the 
object files to be build? 

I have now
--- 8< ---
kde4_add_library( khexeditcommon SHARED ${khexeditcommon_LIB_SRCS} )

if(KDE4_BUILD_TESTS)
add_library( testkhexeditcommon STATIC ${khexeditcommon_LIB_SRCS} )
endif(KDE4_BUILD_TESTS)
--- 8< ---
which results in CMakeFiles/khexeditcommon.dir/*.o and 
CMakeFiles/testkhexeditcommon.dir/*.o

Pardon my limited knowledge, are there any important differences in the object 
files which would hinder such a sharing?

So what I am looking for is a separate, unlinked version of the normal dynamic 
library  in parallel (perhaps slightly different set of object files, but 
with still shared compile flags).

> > (How) could we build separate libraries with some build flag (visibility
> >  here) turned off?
>
> Use set_target_properties to set the COMPILE_FLAGS property which allows
> per-target flags.

Okay, so I just would have to look up the visibility flag, unset it and be 
hopefully done. Will try later.

> > (How) could/should we link to uninstalled libraries (very much
> > appreciated)?
>
> If they are in the same build tree as your programs then just name the
> library.  Otherwise you'll have to find the kde build tree containing
> the libraries you need.  This is not a CMake issue though.

I was perhaps not too clear:
What I want is to not only link, but also bind (correct term?) to the 
uninstalled library when running my (test) app. Right now it binds to the 
installed library version which usually does not include the change I want to 
test :)

> > Are there any plans to "make test/check" trigger a test build like with
> >  auto*? Does this all make sense?
>
> What do you mean by "test build"?

The way I am used to from auto* (pardon :). I could always do a "make check" 
on a plain build with no test app/lib built along before. This also checks 
for dependencies in the test files, builds the needed extra libs/apps and 
runs the (mostly unit) tests. A single, convenient step, done if needed.

This fits smoothly in my work flow (or did I only adopt to it? don't think 
so).

Now the tests with changed dependencies are always build, taking time and log 
data, even if I want to run tests only later. Switching testing included 
builds on and off takes too much steps right now IMHO, sorry to tell :)

> CTest provides 
> nightly/continuous/experimental builds submitting to a dashboard:
>
> http://public.kitware.com/KDE/Testing/Dashboard/MostRecentResults-Nightly/D
>ashboard.html
>
> If you want to build code as part of running a test you can use the
> "ctest --build-and-test" feature to create your test.  Most of CMake's
> internal tests are run this way:
>
> http://www.cmake.org/cgi-bin/viewcvs.cgi/Source/CMakeLists.txt?root=CMake&v
>iew=markup

From what I understand from a first look ctest does not help with the problem 
that with cmake you can only create Makefiles which build always or never 
test libs/apps, right? I am looking not for full automatic testing, but quick 
on-the-fly tests during development:
edit files, "make check"->fail, correct edit, "make check"->passed, go on...

I fear I am not the only one who likes the auto* style? Is there a rational 
why cmake does not support the auto* style of testing right now, or was it 
lack of demand or time?

Thanks :)
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/20060513/81e75285/attachment.pgp