Hi, I'm looking for a way to test the vcardparser. It looks like there is a small test utility in tdeabc and tdeac/vcardparser.
tdeabc/vcardparser$ more README.testing For testing the vcardparser there are some test files and a small testsuite automatically checking for regressions. ... ...
Now with cmake building in test dir
======== mkdir test && cd test && cmake .. cd tdeabc/vcardparser
test/tdeabc/vcardparser$ make check make: *** No rule to make target 'check'. Stop. cd .. test/tdeabc$ make check make: *** No rule to make target 'check'. Stop. ========
but doing the old automake (it does not compile for various reasons) produces a Makefile in vcardparser that (almost) works
======== cd tdelibs-trinity-14.0.3/tdeabc/vcardparser make check make testread testwrite testread2 make[1]: Entering directory '/opt/software_x64/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/vcardparser' g++ -DHAVE_CONFIG_H -I. -I../.. -I../../dcop -I../../kjs -I../../tdecore -I../../tdeio/kssl -I../../tdeabc -I../../tdeabc -I../../dcop -I../../libltdl -I../../tdefx -I../../tdecore -I../../tdecore -I../../tdecore/network -I../../tdeui -I../../tdeio -I../../tdeio/tdeio -I../../tdeio/tdefile -I../.. -I/usr/share/tqt3/include -include tqt.h -I. -I/opt/trinity/include -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT testread.o -MD -MP -MF .deps/testread.Tpo -c -o testread.o testread.cpp In file included from testread.cpp:33:0: ../../tdeabc/vcardconverter.h:26:23: fatal error: addressee.h: No such file or directory #include "addressee.h" ^ compilation terminated. Makefile:710: recipe for target 'testread.o' failed make[1]: *** [testread.o] Error 1 make[1]: Leaving directory '/opt/software_x64/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/vcardparser' Makefile:840: recipe for target 'check-am' failed make: *** [check-am] Error 2 ========
Furthermore cmake refuses to use the src dir and does not produce usable Makefile for the test suite
======== tdelibs-trinity-14.0.3$ cmake . -- The C compiler identification is GNU 4.9.2 -- The CXX compiler identification is GNU 4.9.2 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") CMake Error at cmake/modules/TDEMacros.cmake:24 (message): #################################################
Please use out-of-source building, like this:
rm /opt/software/KDE/TDE/tdelibs-trinity-14.0.3/CMakeCache.txt mkdir /tmp/tdelibs.build cd /tmp/tdelibs.build cmake /opt/software/KDE/TDE/tdelibs-trinity-14.0.3 [arguments...]
################################################# Call Stack (most recent call first): cmake/modules/TDEMacros.cmake:1534 (tde_message_fatal) CMakeLists.txt:39 (include)
-- Configuring incomplete, errors occurred! See also "/opt/software/KDE/TDE/tdelibs-trinity-14.0.3/CMakeFiles/CMakeOutput.log". ========
Let me know what you think about it and should we raise a bug to track and fix it.
thanks in advance
2016-04-23 12:16 GMT+03:00 deloptes deloptes@gmail.com:
Hi, I'm looking for a way to test the vcardparser. It looks like there is a small test utility in tdeabc and tdeac/vcardparser.
tdeabc/vcardparser$ more README.testing For testing the vcardparser there are some test files and a small testsuite automatically checking for regressions. ... ...
Now with cmake building in test dir
======== mkdir test && cd test && cmake .. cd tdeabc/vcardparser
test/tdeabc/vcardparser$ make check make: *** No rule to make target 'check'. Stop. cd .. test/tdeabc$ make check make: *** No rule to make target 'check'. Stop. ========
but doing the old automake (it does not compile for various reasons) produces a Makefile in vcardparser that (almost) works
======== cd tdelibs-trinity-14.0.3/tdeabc/vcardparser make check make testread testwrite testread2 make[1]: Entering directory '/opt/software_x64/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/vcardparser' g++ -DHAVE_CONFIG_H -I. -I../.. -I../../dcop -I../../kjs -I../../tdecore -I../../tdeio/kssl -I../../tdeabc -I../../tdeabc -I../../dcop -I../../libltdl -I../../tdefx -I../../tdecore -I../../tdecore -I../../tdecore/network -I../../tdeui -I../../tdeio -I../../tdeio/tdeio -I../../tdeio/tdefile -I../.. -I/usr/share/tqt3/include -include tqt.h -I. -I/opt/trinity/include -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT testread.o -MD -MP -MF .deps/testread.Tpo -c -o testread.o testread.cpp In file included from testread.cpp:33:0: ../../tdeabc/vcardconverter.h:26:23: fatal error: addressee.h: No such file or directory #include "addressee.h" ^ compilation terminated. Makefile:710: recipe for target 'testread.o' failed make[1]: *** [testread.o] Error 1 make[1]: Leaving directory '/opt/software_x64/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/vcardparser' Makefile:840: recipe for target 'check-am' failed make: *** [check-am] Error 2 ========
Furthermore cmake refuses to use the src dir and does not produce usable Makefile for the test suite
======== tdelibs-trinity-14.0.3$ cmake . -- The C compiler identification is GNU 4.9.2 -- The CXX compiler identification is GNU 4.9.2 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") CMake Error at cmake/modules/TDEMacros.cmake:24 (message): #################################################
Please use out-of-source building, like this:
rm /opt/software/KDE/TDE/tdelibs-trinity-14.0.3/CMakeCache.txt mkdir /tmp/tdelibs.build cd /tmp/tdelibs.build cmake /opt/software/KDE/TDE/tdelibs-trinity-14.0.3 [arguments...]################################################# Call Stack (most recent call first): cmake/modules/TDEMacros.cmake:1534 (tde_message_fatal) CMakeLists.txt:39 (include)
-- Configuring incomplete, errors occurred! See also "/opt/software/KDE/TDE/tdelibs-trinity-14.0.3/CMakeFiles/CMakeOutput.log". ========
Let me know what you think about it and should we raise a bug to track and fix it.
thanks in advance
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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...
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
thanks and regards
In article nfi6e4$c7s$1@ger.gmane.org, deloptes trinity-devel@lists.pearsoncomputing.net 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
Nick Leverton wrote:
In article nfi6e4$c7s$1@ger.gmane.org, deloptes
trinity-devel@lists.pearsoncomputing.net
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
In article nfm6a9$8te$1@ger.gmane.org, deloptes trinity-devel@lists.pearsoncomputing.net wrote:
Nick Leverton wrote:
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.
You've probably already had this idea too :-) but LD_PRELOAD may be of interest to load only specific libraries from your test build ?
Nick
Nick Leverton wrote:
In article nfm6a9$8te$1@ger.gmane.org, deloptes
trinity-devel@lists.pearsoncomputing.net
wrote:
Nick Leverton wrote:
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.
You've probably already had this idea too :-) but LD_PRELOAD may be of interest to load only specific libraries from your test build ?
Nick
Thanks Nick, thanks all! I am not sure how I can compile tdelib/tdeabc and link to it a test program. The runtime thing is something I have done. I have also compiled test code, but in this case it is in the library. Unfort. I'm too busy this week. I'll try out the ideas you gave next and be back to you later.
regards
On 04/23/2016 07:16 PM, deloptes wrote:
Hi, I'm looking for a way to test the vcardparser. It looks like there is a small test utility in tdeabc and tdeac/vcardparser.
tdeabc/vcardparser$ more README.testing For testing the vcardparser there are some test files and a small testsuite automatically checking for regressions. ... ...
Now with cmake building in test dir
======== mkdir test && cd test && cmake .. cd tdeabc/vcardparser
test/tdeabc/vcardparser$ make check make: *** No rule to make target 'check'. Stop. cd .. test/tdeabc$ make check make: *** No rule to make target 'check'. Stop. ========
but doing the old automake (it does not compile for various reasons) produces a Makefile in vcardparser that (almost) works
======== cd tdelibs-trinity-14.0.3/tdeabc/vcardparser make check make testread testwrite testread2 make[1]: Entering directory '/opt/software_x64/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/vcardparser' g++ -DHAVE_CONFIG_H -I. -I../.. -I../../dcop -I../../kjs -I../../tdecore -I../../tdeio/kssl -I../../tdeabc -I../../tdeabc -I../../dcop -I../../libltdl -I../../tdefx -I../../tdecore -I../../tdecore -I../../tdecore/network -I../../tdeui -I../../tdeio -I../../tdeio/tdeio -I../../tdeio/tdefile -I../.. -I/usr/share/tqt3/include -include tqt.h -I. -I/opt/trinity/include -DQT_THREAD_SUPPORT -D_REENTRANT -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT testread.o -MD -MP -MF .deps/testread.Tpo -c -o testread.o testread.cpp In file included from testread.cpp:33:0: ../../tdeabc/vcardconverter.h:26:23: fatal error: addressee.h: No such file or directory #include "addressee.h" ^ compilation terminated. Makefile:710: recipe for target 'testread.o' failed make[1]: *** [testread.o] Error 1 make[1]: Leaving directory '/opt/software_x64/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/vcardparser' Makefile:840: recipe for target 'check-am' failed make: *** [check-am] Error 2 ========
Furthermore cmake refuses to use the src dir and does not produce usable Makefile for the test suite
======== tdelibs-trinity-14.0.3$ cmake . -- The C compiler identification is GNU 4.9.2 -- The CXX compiler identification is GNU 4.9.2 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28") CMake Error at cmake/modules/TDEMacros.cmake:24 (message): #################################################
Please use out-of-source building, like this:
rm /opt/software/KDE/TDE/tdelibs-trinity-14.0.3/CMakeCache.txt mkdir /tmp/tdelibs.build cd /tmp/tdelibs.build cmake /opt/software/KDE/TDE/tdelibs-trinity-14.0.3 [arguments...]################################################# Call Stack (most recent call first): cmake/modules/TDEMacros.cmake:1534 (tde_message_fatal) CMakeLists.txt:39 (include)
-- Configuring incomplete, errors occurred! See also "/opt/software/KDE/TDE/tdelibs-trinity-14.0.3/CMakeFiles/CMakeOutput.log". ========
Let me know what you think about it and should we raise a bug to track and fix it.
thanks in advance
Hi Emanoil, I have not looked at this in detail, but at first sight the tdeabc/tests folder does not contain any CMakeList.txt. In my log file in fact, I do not find any reference to tde/tests, not surprisingly. You could try adding a CMakeList.txt file and see what happens. Regarding tdeunittest, I see in the build log that it gets built. Nevertheless trying to run it from CLI (/opt/trinity/bin/tdeunittestmodrunner) gives a not so good "# Running normal tests... # All 0 tests passed" output, suggesting no tests have been run at all. I have never used it before, so perhaps I am doing something wrong, but it is quite possible that instead it is broken as Fat-Zer suggested.
Cheers Michele
Michele Calgaro wrote:
Hi Emanoil, I have not looked at this in detail, but at first sight the tdeabc/tests folder does not contain any CMakeList.txt. In my log file in fact, I do not find any reference to tde/tests, not surprisingly. You could try adding a CMakeList.txt file and see what happens. Regarding tdeunittest, I see in the build log that it gets built. Nevertheless trying to run it from CLI (/opt/trinity/bin/tdeunittestmodrunner) gives a not so good "# Running normal tests... # All 0 tests passed" output, suggesting no tests have been run at all. I have never used it before, so perhaps I am doing something wrong, but it is quite possible that instead it is broken as Fat-Zer suggested.
Cheers Michele
Ah, thanks, this is exactly what I was looking for. It has been a couple of years since I last created CMakeList.txt . I think I would need a refresh of this part of my memory - it wasn't thaaaat hard as the automake stuff. From what I understood the test suite can be used prior to installation and this would be handy in the case I have. The tests included are idiotic, as there is no single non ascii char in them - but perhaps utf was on non of the devices 10-15 years ago.
I think one has to first have the binary and test material in the right place and do the testing after this, but cmake requires directory different than project root. There might be also something in Fat-Zers statement. Ufff - anyway - thanks for the hint.
New query: 1. Is there a good way to convert the Makefile.am into CMakeList.txt? 2. Is there an alternative way to test the library with the function of interest without installing it?
I lack time and experience for this specific case.
BTW I just pulled tdelibs from git and got all recent fixes - it works great. Thanks for the regex on the datetime issue - it's also very nice.
regards
regards
Ah, thanks, this is exactly what I was looking for. It has been a couple of years since I last created CMakeList.txt . I think I would need a refresh of this part of my memory - it wasn't thaaaat hard as the automake stuff.
Copy one from another folder (example from vcard or vcardfolder) and modify from there. Easier way to learn something ;-)
New query:
- Is there a good way to convert the Makefile.am into CMakeList.txt?
- Is there an alternative way to test the library with the function of
interest without installing it?
You can create a small test program with your test code, compile and execute. That should be reasonably quick. No need to set any special linking folder, if you have everything installed correctly if should just find the right function in the right library file by itself. That is how I tested that regex code in VCardTool
Cheers Michele
Michele Calgaro wrote:
Ah, thanks, this is exactly what I was looking for. It has been a couple of years since I last created CMakeList.txt . I think I would need a refresh of this part of my memory - it wasn't thaaaat hard as the automake stuff.
Copy one from another folder (example from vcard or vcardfolder) and modify from there. Easier way to learn something ;-)
New query:
- Is there a good way to convert the Makefile.am into CMakeList.txt?
- Is there an alternative way to test the library with the function of
interest without installing it?
You can create a small test program with your test code, compile and execute. That should be reasonably quick. No need to set any special linking folder, if you have everything installed correctly if should just find the right function in the right library file by itself. That is how I tested that regex code in VCardTool
Cheers Michele
I created usable CMakeList.txt to compile tests in tdeabc. This I did by extending the present CMakeList.txt file with some information from the Makefile.am. This is almost working. The problem I face is this
[ 71%] Building CXX object tdeabc/tests/CMakeFiles/testldapclient.dir/testldapclient.cpp.o /opt/software/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/tests/testldapclient.cpp:161:30: fatal error: testldapclient.moc: No such file or directory #include "testldapclient.moc" ^ Can you advise how one could tell CMake to create (and use) testldapclient.moc ?
Next thing to do is to make possible compiling the tests for vcardparser.
thanks in advance
regards
On 2016/05/02 05:08 AM, deloptes wrote:
Michele Calgaro wrote:
Ah, thanks, this is exactly what I was looking for. It has been a couple of years since I last created CMakeList.txt . I think I would need a refresh of this part of my memory - it wasn't thaaaat hard as the automake stuff.
Copy one from another folder (example from vcard or vcardfolder) and modify from there. Easier way to learn something ;-)
New query:
- Is there a good way to convert the Makefile.am into CMakeList.txt?
- Is there an alternative way to test the library with the function of
interest without installing it?
You can create a small test program with your test code, compile and execute. That should be reasonably quick. No need to set any special linking folder, if you have everything installed correctly if should just find the right function in the right library file by itself. That is how I tested that regex code in VCardTool
Cheers Michele
I created usable CMakeList.txt to compile tests in tdeabc. This I did by extending the present CMakeList.txt file with some information from the Makefile.am. This is almost working. The problem I face is this
[ 71%] Building CXX object tdeabc/tests/CMakeFiles/testldapclient.dir/testldapclient.cpp.o /opt/software/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/tests/testldapclient.cpp:161:30: fatal error: testldapclient.moc: No such file or directory #include "testldapclient.moc" ^ Can you advise how one could tell CMake to create (and use) testldapclient.moc ?
Next thing to do is to make possible compiling the tests for vcardparser.
thanks in advance
regards
Hi Emanoil,can you share the cmakelist file you created? i will try to take a look at this later during the second part of week. Cheers Michele
Michele Calgaro wrote:
On 2016/05/02 05:08 AM, deloptes wrote:
Michele Calgaro wrote:
Ah, thanks, this is exactly what I was looking for. It has been a couple of years since I last created CMakeList.txt . I think I would need a refresh of this part of my memory - it wasn't thaaaat hard as the automake stuff.
Copy one from another folder (example from vcard or vcardfolder) and modify from there. Easier way to learn something ;-)
New query:
- Is there a good way to convert the Makefile.am into CMakeList.txt?
- Is there an alternative way to test the library with the function of
interest without installing it?
You can create a small test program with your test code, compile and execute. That should be reasonably quick. No need to set any special linking folder, if you have everything installed correctly if should just find the right function in the right library file by itself. That is how I tested that regex code in VCardTool
Cheers Michele
I created usable CMakeList.txt to compile tests in tdeabc. This I did by extending the present CMakeList.txt file with some information from the Makefile.am. This is almost working. The problem I face is this
[ 71%] Building CXX object tdeabc/tests/CMakeFiles/testldapclient.dir/testldapclient.cpp.o /opt/software/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/tests/testldapclient.cpp:161:30: fatal error: testldapclient.moc: No such file or directory #include "testldapclient.moc" ^ Can you advise how one could tell CMake to create (and use) testldapclient.moc ?
Next thing to do is to make possible compiling the tests for vcardparser.
thanks in advance
regards
Hi Emanoil,can you share the cmakelist file you created? i will try to take a look at this later during the second part of week. Cheers Michele
Thanks Michele! If you can also check also following (the list of issues I had): - bigread and bigwrite crash with double link error - testdb does not compile (see TODO) - testldapclient.moc not generated
thank you in advance and regards
On Monday 02 of May 2016 08:05:36 deloptes wrote:
Michele Calgaro wrote:
On 2016/05/02 05:08 AM, deloptes wrote:
Michele Calgaro wrote:
Ah, thanks, this is exactly what I was looking for. It has been a couple of years since I last created CMakeList.txt . I think I would need a refresh of this part of my memory - it wasn't thaaaat hard as the automake stuff.
Copy one from another folder (example from vcard or vcardfolder) and modify from there. Easier way to learn something ;-)
New query:
- Is there a good way to convert the Makefile.am into CMakeList.txt?
- Is there an alternative way to test the library with the function
of interest without installing it?
You can create a small test program with your test code, compile and execute. That should be reasonably quick. No need to set any special linking folder, if you have everything installed correctly if should just find the right function in the right library file by itself. That is how I tested that regex code in VCardTool
Cheers Michele
I created usable CMakeList.txt to compile tests in tdeabc. This I did by extending the present CMakeList.txt file with some information from the Makefile.am. This is almost working. The problem I face is this
[ 71%] Building CXX object tdeabc/tests/CMakeFiles/testldapclient.dir/testldapclient.cpp.o /opt/software/KDE/TDE/tdelibs-trinity-14.0.3/tdeabc/tests/testldapclient .cpp:161:30: fatal error: testldapclient.moc: No such file or directory #include "testldapclient.moc" ^ Can you advise how one could tell CMake to create (and use) testldapclient.moc ?
Next thing to do is to make possible compiling the tests for vcardparser.
thanks in advance
regards
Hi Emanoil,can you share the cmakelist file you created? i will try to take a look at this later during the second part of week. Cheers Michele
Thanks Michele! If you can also check also following (the list of issues I had):
- bigread and bigwrite crash with double link error
- testdb does not compile (see TODO)
- testldapclient.moc not generated
thank you in advance and regards
You can try to use the supplied patch. It is a little simpler and uses standard TDE macros.
On 05/08/2016 03:12 AM, Slávek Banko wrote:
Thanks Michele! If you can also check also following (the list of issues I had):
- bigread and bigwrite crash with double link error
- testdb does not compile (see TODO)
- testldapclient.moc not generated
thank you in advance and regards
You can try to use the supplied patch. It is a little simpler and uses standard TDE macros.
Looks like Slavek has been quicker than me :-) Let us know how it goes Emanoil.
Cheers Michele
Michele Calgaro wrote:
Looks like Slavek has been quicker than me :-) Let us know how it goes Emanoil.
Hi, thanks to both of you, patch works and most of the tests in tdeabc work now as well - actually bigread/write crashes with double link error as before. The most exciting part is, however, with the vcardparser.
1. Based on the nice work by Slavek I produced CMakeLists.txt and compiled the vcardparser tests. The patch proposed by Fat-Zer works only half the way, so it looks like there is something else that needs to be fixed (and was the reason I was suffering the double conversion). With his patch and explicitly useing utf8 it does the tests properly. Example in testread2/testutils: Addressee addr;
addr.setName( "Jahn Böhmermann" ); addr.setOrganization( "HansWürstel AG" ); ... Address a( Address::Work ); a.setStreet( "Müllerstrasse 21" ); does not work, but Addressee addr;
addr.setName( TQString::fromUtf8("Jahn Böhmermann") ); addr.setOrganization( TQString::fromUtf8("HansWürstel AG") ); ... Address a( Address::Work ); a.setStreet( TQString::fromUtf8("Müllerstrasse 21") ); works in the test code.
I'll be back when I have some meaningful results and finalize the patch with the test files with utf8 chars next. The latter seems to be doable in 1-2days and I hope you could also have a look at the results and provide some hints when tests can be easily performed.
2. the tests are not completed and I see a problem with setting the proper name from "N:Böhmermann;Jahn;" results in Addressee { Name: '' FormattedName: 'Jahn Böhmermann' FamilyName: 'Böhmermann' GivenName: 'Jahn'
which is simply not correct This also needs investigation as I think from the sync side all worked good and I have not seen any problem AFAIR.
thanks anyway and have a good week
Hi, this patch adds testing vcardparser to cmake, so that the code compiles and is usable.
1. I did not add check target as in the original automake, but rather added a test.sh script that can be executed from within vcardparser directory.
2. The patch also includes the patch by Fat-Zer, which works for the testing tools, but as I reported before, it results in utf8 converted chars each time I load kontact (each time vcf file is read (and perhaps written)). To me it looks like parseVCards is good with that patch but there is a problem elsewhere in the chain - write??(see 4).
3. I added two tests in utf8 tests/vcard8.vcf (german) tests/vcard9.vcf (cyrillic) and have no idea why vcard9 fails on testread2 and why the Name is not read properly, when in vcard8 it passes the test
4. I then added a testwrite2 file that exposes the problem with the utf8 to utf8 conversion and will look into it next.
all together we are 1 step further
[to be continued]
regards
PS: Unfortunately when building debian packages it adds X-Ubuntu-Gettext-Domain=desktop_tdelibs-trinity to each desktop source file, which is really bad.
I quick workaround it like following find . -name '*.desktop' -exec grep X-Ubuntu-Gettext-Domain {} ; -print | grep '^./' | while read line; do echo ">>>" $line; perl -pi -e 's:X-Ubuntu-Gettext-Domain=desktop_tdelibs-trinity::g' $line; done
Slávek Banko wrote:
On Monday 02 of May 2016 08:05:36 deloptes wrote:
You can try to use the supplied patch. It is a little simpler and uses standard TDE macros.
Hi, attached the final patch for the vcardparser, vcardformatplugin and testing.
The final problem identified in vcardformatplugin
--- a/tdelibs.orig/tdeabc/vcardformatplugin.cpp +++ b/tdelibs-trinity-14.0.3/tdeabc/vcardformatplugin.cpp @@ -41,7 +41,7 @@ bool VCardFormatPlugin::load( Addressee &addressee, TQFile *file ) TQString data;
TQTextStream t( file ); - t.setEncoding( TQTextStream::Latin1 ); + t.setEncoding( TQTextStream::UnicodeUTF8 ); data = t.read();
but writing to the file sets TQTextStream::UnicodeUTF8.
Patch by Fat-Zer included and testing stuff as explained in the previous message.
I tested it already and don't see any issue. It is however debatable if we should not test encoding based on locale, but I doubt someone today is using something different than utf8
regards
-
deloptes -
Fat-Zer -
Michele Calgaro -
Nick Leverton -
Slávek Banko