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
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
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
2016-06-19 15:41 GMT+03:00 deloptes deloptes@gmail.com:
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 ALLI 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
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.
Fat-Zer wrote:
Some notes to be taken into account:
- 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
2016-06-21 9:23 GMT+03:00 deloptes deloptes@gmail.com:
Fat-Zer wrote:
Some notes to be taken into account:
- 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
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...
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
-
deloptes -
Fat-Zer