(Resent, as the first post seems to be lost:) Hi Alex, :)
Am Samstag, 13. Mai 2006 18:37, schrieb Alexander Neundorf:
> On Saturday 13 May 2006 14:14, Friedrich W. H. Kossebau wrote:
> > 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.
Yes, _could_. But what if I know and want that they are not? See the example
above: I want to create from the very same object files a static lib next to
the linked dynamic one because this seems to be needed for convenient unit
testing (due to symbol visibility, see the reference below).
> > > 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...)
I do this already, and yes, it links to the uninstalled in the build, then
binds(?) to the installed if running!
Test yourself:
1. remove some visibility flag for a class in a lib, compile, install
2. put flag back, compile and link lib, but do not install
3. compile and link some not installed executable (e.g. a test) which needs
that class symbol
4. run executable -> symbol lookup error
5. install new lib from above -> executable runs fine...
> What do you actually need the static libs for ?
For what this thread started from, please read
http://mail.kde.org/pipermail/kde-buildsystem/2006-May/002726.html
> > 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.
Ah, good to know: What kind of chocolate do you prefer as bribe? :P
> 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 ?
I am looking for convenient adhoc testing which can be applied in the middle
of some development session without effects on the rest of that session. E.g.
for test-driven development.
Workflow: Edit, compile, edit, compile and run tests ->fails, edit again,
compile and run tests ->ok, edit, compile, edit, compile, edit, compile and
run test ->ok, edit, compile, edit, ...
So this is a different use case from what seems supported now only, namely
nightly automatic builds. Can you better guess now what I (and others)
want? :)
auto*'s "make" and "make check" do fit nicely there. The default target(s) do
not include dependencies on the test targets. Only on the target "check" all
test dependencies are run, then automatically the tests executed.
Could something like this be included?
Are flags like KDE4_BUILD_TESTS binary or could the support for auto*-style
testing be requested by e.g. "-D KDE4_BUILD_TESTS=2"?
Thanks
Friedrich
pgp246JCYyIOD.pgp
Description: PGP signature
_______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
