17 Jun
2016
17 Jun
'16
8:08 a.m.
Hi again,
I'm sorry to bother you again with this, but I asked once how I can add a
testing target.
I started then working on this tdepim libkcal testing stuff again. I still
have some issues when my "SUMMARY" or "DESCRIPTION" of event or todo
are in
cyrillic. Unfortunately I was/am busy at work and I lost all threads ....
perhaps you know this feeling ... getting older.
I also found the key to building testing targets
DEB_MAKE_CHECK_TARGET=testing fakeroot debian/rules build
so I think the next exercise (may be long term one) would be to revive the
check/testing code laying around.
I think I have a good plan
1. fix the libkcal issue "SUMMARY" - "DESCRIPTION"
2. build syncevolution deb packages for TDE
3. fix the libkcal test cases (now a lot of them fail on some date issue -
perhaps because originally there was a local zoneinfo data included in the
code and now it is not there)
4. start migrating testing to CMake (first in the packages I already have
worked with)
what do you think?
regards
19 Jun
19 Jun
12:22 a.m.
deloptes wrote:
add_custom_target(testing check
COMMAND bash test.sh
COMMENT .......
DEPENDS .......
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
does this look good to you
especially add_custom_target(testing check
thanks
5:41 a.m.
deloptes wrote:
deloptes wrote:
add_custom_target(testing check
COMMAND bash test.sh
COMMENT .......
DEPENDS .......
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
does this look good to you
especially add_custom_target(testing check
thanks
I tested now and it seems it should be
add_custom_target(testing ALL
I don't see any other option in docs except all or skip this, but ALL also
means it should pass the tests as the target is called on build and if
skipped the testing target can not be called
fakeroot debian/rules testing
...
make: *** No rule to make target 'testing'. Stop.
Another problem I have with
COMMAND bash test.sh
is that it tries executing this but test is not created at this point of
time. However I have defined
add_custom_command(
TARGET testing PRE_BUILD
COMMAND test
ARGS -f ${CMAKE_CURRENT_BINARY_DIR}/test.sh || ln -s
${CMAKE_CURRENT_SOURCE_DIR}/test.sh ${CMAKE_CURRENT_BINARY_DIR}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
Can you help a bit please?
thanks
20 Jun
20 Jun
3:09 p.m.
New subject: [trinity-devel] Re: test target and code
2016-06-19 15:41 GMT+03:00 deloptes <deloptes(a)gmail.com>om>:
deloptes wrote:
Hi, I was played around with repairing the check/test system some time ago...
Some notes to be taken into account:
1) There are two types of checks:
- "make check" builds test snippets that are required to be run by
the user and see if they produce correct output
- "make test" runs those few which are intended to be run as part
of automatic system
2) The programs themselves are broken (mostly they have same mistake
related to changed TDEApplication constructor signature)
I may fix the cmake stuff for you, if you will repair the programs
themselves (95% is to change 1 line, but I wouldn't trust in that
particular case to a script) and do the testing (at least make sure
that all checks are getting run and won't crash instantly).
Also for doing it right I will follow the order: tdelibs -> tdebase -> tdepim.
Note to maintainers: changes to the main cmake files will be required.
deloptes wrote:
add_custom_target(testing check
COMMAND bash test.sh
COMMENT .......
DEPENDS .......
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
does this look good to you
especially add_custom_target(testing check
thanks
I tested now and it seems it should be
add_custom_target(testing ALL
I don't see any other option in docs except all or skip this, but ALL also
means it should pass the tests as the target is called on build and if
skipped the testing target can not be called
fakeroot debian/rules testing
...
make: *** No rule to make target 'testing'. Stop.
Another problem I have with
COMMAND bash test.sh
is that it tries executing this but test is not created at this point of
time. However I have defined
add_custom_command(
TARGET testing PRE_BUILD
COMMAND test
ARGS -f ${CMAKE_CURRENT_BINARY_DIR}/test.sh || ln -s
${CMAKE_CURRENT_SOURCE_DIR}/test.sh ${CMAKE_CURRENT_BINARY_DIR}
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
Can you help a bit please?
thanks
11:23 p.m.
Fat-Zer wrote:
Some notes to be taken into account:
1) There are two types of checks:
- "make check" builds test snippets that are required to be run by
the user and see if they produce correct output
- "make test" runs those few which are intended to be run as part
of automatic system
2) The programs themselves are broken (mostly they have same mistake
related to changed TDEApplication constructor signature)
This sounds good. Thank you!
I may fix the cmake stuff for you, if you will repair
the programs
themselves (95% is to change 1 line, but I wouldn't trust in that
particular case to a script) and do the testing (at least make sure
that all checks are getting run and won't crash instantly).
Indeed I have noticed this. An example is the tdepim calendar tests I tried
recently. When there is DTSTART; DATE: 20030901, I get in the test result
file DTSTART: 201606......T.....Z
It could be we broke something by fixing the null date/time issue
Also for doing it right I will follow the order:
tdelibs -> tdebase ->
tdepim.
This is also a good hint. Thanks
regards
22 Jun
22 Jun
10:26 a.m.
New subject: [trinity-devel] Re: Re: test target and code
2016-06-21 9:23 GMT+03:00 deloptes <deloptes(a)gmail.com>om>:
Fat-Zer wrote:
So, are you ok to fixing and testing bunches of stuff in
tdelibs&tdebase? If so, I start the cmake stuff...
I don't want either to do this quite boring and low-requred job all by
myself or to stuck with the job half-done...
Some notes to be taken into account:
1) There are two types of checks:
- "make check" builds test snippets that are required to be run by
the user and see if they produce correct output
- "make test" runs those few which are intended to be run as part
of automatic system
2) The programs themselves are broken (mostly they have same mistake
related to changed TDEApplication constructor signature)
This sounds good. Thank you!
I may fix the cmake stuff for you, if you will
repair the programs
themselves (95% is to change 1 line, but I wouldn't trust in that
particular case to a script) and do the testing (at least make sure
that all checks are getting run and won't crash instantly).
Indeed I have noticed this. An example is the tdepim calendar tests I tried
recently. When there is DTSTART; DATE: 20030901, I get in the test result
file DTSTART: 201606......T.....Z
It could be we broke something by fixing the null date/time issue
Also for doing it right I will follow the order:
tdelibs -> tdebase ->
tdepim.
This is also a good hint. Thanks
26 Jun
26 Jun
8:12 a.m.
Fat-Zer wrote:
So, are you ok to fixing and testing bunches of stuff
in
tdelibs&tdebase? If so, I start the cmake stuff...
I don't want either to do this quite boring and low-requred job all by
myself or to stuck with the job half-done...
Yes I am OK doing this as far as I can. It would be good to have one around
who cares as well.
I think there is an obvious benefit in having the test system working - and
yes it looks like boring, but given the benefit it should pay off. I am not
in hurry, but I think one should setup the cmake stuff, so that I or
someone can update the tests and package by package somewhen all testing
will be active.
regards
PS: sorry for late response - priorities
3073
days inactive
3082
days old
6 comments
2 participants
participants (2)
-
deloptes -
Fat-Zer