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

[Alexander Neundorf]

Hi,

On Saturday 13 May 2006 14:14, Friedrich W. H. Kossebau wrote:
> Hi Brad,
>
> thanks for your answer.
...
> 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?

Different targets could be built with different flags etc., so the object 
files could differ. That's why the object files are not reused.

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

So you link to libkfoosomething.so, and when running the app, it links to the 
installed lib instead of the not-yet-installed one ?
Then use the RUN_UNINSTALLED option for KDE4_ADD_EXECUTABLE:
KDE4_ADD_EXECUTABLE(kfoo RUN_UNINSTALLED srcs...)

What do you actually need the static libs for ?

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

It is because I implemented it this way.
The unit tests are only built if tzhe option BUILD_TESTS is enabled. The unit 
tests could also be built as a special target.
If your real problem is that a small change in any of the cmake files cause a 
quite long cmake run, we should have a look where cmake spends the time and 
check whether this can be improved.
Or do you actually mean to execute the tests using a make target ? There is 
probably a target to do this.
Or are you more looking for something like the ctest --build-and-test option ?

Bye
Alex
-- 
Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de
Home: neundorf AT kde.org                - http://www.kde.org
      alex AT neundorf.net               - http://www.neundorf.net