23 Apr
2016
23 Apr
'16
9:16 a.m.
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
24 Apr
24 Apr
4:37 a.m.
New subject: [trinity-devel] testing: tdeabc/vcardparser$ more README.testing
2016-04-23 12:16 GMT+03:00 deloptes <deloptes(a)gmail.com>om>:
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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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...
10:16 a.m.
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
10:45 a.m.
New subject: [trinity-devel] testing: tdeabc/vcardparser$ more README.testing
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
8:52 p.m.
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
25 Apr
25 Apr
10:15 p.m.
In article <nfi6e4$c7s$1(a)ger.gmane.org>rg>,
deloptes <trinity-devel(a)lists.pearsoncomputing.net> wrote:
Fat-Zer wrote:
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
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996
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
10:39 p.m.
Nick Leverton wrote:
In article <nfi6e4$c7s$1(a)ger.gmane.org>rg>,
deloptes
<trinity-devel(a)lists.pearsoncomputing.net>
wrote:
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
Fat-Zer wrote:
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 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
26 Apr
26 Apr
10:55 a.m.
New subject: [trinity-devel] Re: testing: tdeabc/vcardparser$ more README.testing
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:
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?
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
27 Apr
27 Apr
2:20 p.m.
In article <nfm6a9$8te$1(a)ger.gmane.org>rg>,
deloptes <trinity-devel(a)lists.pearsoncomputing.net> wrote:
Nick Leverton wrote:
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
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996
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.
7:01 p.m.
Nick Leverton wrote:
In article <nfm6a9$8te$1(a)ger.gmane.org>rg>,
deloptes
<trinity-devel(a)lists.pearsoncomputing.net>
wrote:
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
Nick Leverton wrote:
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 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.
1 May
1 May
7:08 p.m.
Michele Calgaro wrote:
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
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:
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?
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
2 May
2 May
12:48 a.m.
New subject: [trinity-devel] Re: Re: testing: tdeabc/vcardparser$ more README.testing
On 2016/05/02 05:08 AM, deloptes wrote:
Michele Calgaro wrote:
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
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:
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?
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
6:05 a.m.
Michele Calgaro wrote:
On 2016/05/02 05:08 AM, deloptes 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
Michele Calgaro wrote:
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 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:
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?
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 
7 May
7 May
5:12 p.m.
New subject: [trinity-devel] Re: Re: Re: testing: tdeabc/vcardparser$ more README.testing
On Monday 02 of May 2016 08:05:36 deloptes wrote:
Michele Calgaro wrote:
You can try to use the supplied patch. It is a little simpler and uses
standard TDE macros.
--
Slávek
On 2016/05/02 05:08 AM, deloptes 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 Michele Calgaro wrote:
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 > 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:
> 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?
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
8 May
8 May
11:35 a.m.
New subject: [trinity-devel] Re: Re: Re: testing: tdeabc/vcardparser$ more README.testing
On 05/08/2016 03:12 AM, Slávek Banko wrote:
Looks like Slavek has been quicker than me :-)
Let us know how it goes Emanoil.
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.
11:35 p.m.
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
9 May
9 May
11:17 p.m.
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
10 May
10 May
10:54 a.m.
New subject: testing: tdeabc/vcardparser$ more README.testing [solved]
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
2910
days inactive
2927
days old
17 comments
5 participants
participants (5)
-
deloptes -
Fat-Zer -
Michele Calgaro -
Nick Leverton -
Slávek Banko