Nick Leverton wrote: > In article <nfi6e4$c7s$1@...>, > deloptes > <trinity-devel@...> > wrote: >>Fat-Zer wrote: >> >>> The testing framework wasn't introduced with migration to cmake. I >>> believe that autotools unittests are broken as well now... >>> IMHO it would be great to bring unittesting back, but this is a bit >>> tough tasks which will be likely postponed forever... I personally not >>> familiar with cmake testing in general... >> >>Thanks for looking into my issues >>Is there a way in your opinion how we can test the vcardparser? >>I was thinking overwriting the library files, but I'm not sure if the >>libtdeabc.so.1.2.0 is the only one I should overwrite and if I have to >>restart or reboot or whatever > > You could perhaps set the LD_LIBRARY_PATH environment variable to point > to your test libraries and run an existing program against them. > The Linux loader ld.so searches directories named in LD_LIBRARY_PATH > before falling back to the system library directories. For instance > > LD_LIBRARY_PATH=/path/to/libs/ kaddressbook > > See "man ld.so" for full details. > > Nick Thank you for the advise. I was also thinking of doing something like this. I know ld pretty well BTW, but in the case of the tdelibs I am not sure, because there are many libs besides the libtdeabc.so. I'm not sure how it will behave and don't want to experiment that much. Not that I do not like it, but because recently the available time is short and I try to focus on one problem. It happens as usual: you dig a bit in the hope you'll fix something and than you hit another issue - dig a bit and s.o. I'll give it a try. I suppose ldd will tell me if the app is getting the lib of interest loaded. regards