Posts tonen met het label gsoc. Alle posts tonen
Posts tonen met het label gsoc. Alle posts tonen
dinsdag 13 mei 2008
Milestone 2
I plugged QxRunner into Kdevelop4, as planned. While still far from fully functional it's nice to see some progress anyway. The screenshot below shows a small CppUnit suite. It's not dynamic at all though, just compiled in the hard way. I'm, however, quite happy with how it turned out visually. Might have to remove the result view (widget in the lower left corner) with something more flexible though, maybe based on the filesystem-plugin scroll thingy.
zaterdag 10 mei 2008
g++ linkage on 64 bit
/usr/bin/ld: /home/nix/KdeDev/kdevelop/build/lib/libqxcppunit.a(testrunner.o):
relocation R_X86_64_32S against `vtable for QxCppUnit::TestRunner' can not be
used when making a shared object; recompile with -fPIC
/home/nix/KdeDev/kdevelop/build/lib/libqxcppunit.a: could not read symbols:
Bad value
collect2: ld returned 1 exit status
make[2]: *** [lib/kdevxtest.so] Error 1
A cookie for those that decipher this g++ gibberish. And yes, "-fPIC" was present. Apaku, who's mentoring me, told me this happens when you try to link a static library into a shared one. Apparently this is not supported in the 64bit gcc implementation and hence forbidden in KDE. Funnily enough the same construct runs without a hitch on x86.
Related to this I learned about gcc's DSO visibility concept. Marking symbols as visible in a shared library is typically done with an export macro. In the original QxRunner this macro was activated externally by the buildsystem, which I overlooked when converting to CMake. This resulted in totally mangled shared libs ... not good.
relocation R_X86_64_32S against `vtable for QxCppUnit::TestRunner' can not be
used when making a shared object; recompile with -fPIC
/home/nix/KdeDev/kdevelop/build/lib/libqxcppunit.a: could not read symbols:
Bad value
collect2: ld returned 1 exit status
make[2]: *** [lib/kdevxtest.so] Error 1
A cookie for those that decipher this g++ gibberish. And yes, "-fPIC" was present. Apaku, who's mentoring me, told me this happens when you try to link a static library into a shared one. Apparently this is not supported in the 64bit gcc implementation and hence forbidden in KDE. Funnily enough the same construct runs without a hitch on x86.
Related to this I learned about gcc's DSO visibility concept. Marking symbols as visible in a shared library is typically done with an export macro. In the original QxRunner this macro was activated externally by the buildsystem, which I overlooked when converting to CMake. This resulted in totally mangled shared libs ... not good.
dinsdag 6 mei 2008
QxRunner test suite
While coding hasn't officialy started yet I just finished the first milestone. The base for the test runner is going to be QxRunner, however this didnt have a test suite of it's own, yet. By coding this I achieved a double purpose (i) get to know the internals inside out and (ii) create a safety net for comming changes.
The initial goal was 90% coverage, although it never got specificied what kind of coverage, be it class, method, block, statement, branch ... In the end I achieved 70% line coverage which is a whole lot indeed. The remaining bits werent really worth exercising imo, view report. I measured this with gcc's gcov and visualized it with lcov.
The initial goal was 90% coverage, although it never got specificied what kind of coverage, be it class, method, block, statement, branch ... In the end I achieved 70% line coverage which is a whole lot indeed. The remaining bits werent really worth exercising imo, view report. I measured this with gcc's gcov and visualized it with lcov.
maandag 21 april 2008
Acceptance!
The accepted Google Summer of Code projects have just been announced and ... my xUnit Kdevelop4 related one got through! It is happening :) Getting paid by google to hack on KDE, just great.
Andreas Pakulat is going to be my mentor. He is an experienced Qt and KDE developer, whats more he gets paid paid to code on test related software: squish . The right person for the job for sure!
Andreas Pakulat is going to be my mentor. He is an experienced Qt and KDE developer, whats more he gets paid paid to code on test related software: squish . The right person for the job for sure!
donderdag 27 maart 2008
Fetch python
My second, slightly preferred, proposal is related to Fetch. I've contributed to the project and use it for my Bachelor year assignment, Tsmells. Fact extraction for python would be awesome, to say the least.
The goal of this project is python support for Fetch. Fetch is an open source tool chain which performs static analysis on object oriented software systems. Use cases include architectural conformance checking and re-documentation, model querying by developers, internal quality trending and effort estimation based upon static analysis. Currently C/C++ and Java are accepted as input languages.
Since UA is not a mentoring organization (did not apply), I submitted this proposal as a 'no_org'. Bart Van Rompaey has agreed to mentor me on this.
The goal of this project is python support for Fetch. Fetch is an open source tool chain which performs static analysis on object oriented software systems. Use cases include architectural conformance checking and re-documentation, model querying by developers, internal quality trending and effort estimation based upon static analysis. Currently C/C++ and Java are accepted as input languages.
Since UA is not a mentoring organization (did not apply), I submitted this proposal as a 'no_org'. Bart Van Rompaey has agreed to mentor me on this.
Kdevelop application
As part of a greater scheme - promote testing in FOSS - I want to code state of the art xUnit support for kdevelop as a gsoc.
Here's the abstract:
The goal of this project is support for xUnit frameworks in Kdevelop4. More specific: QtUnit, CppUnit, Check and PyUnit.
Automated testing with the aid of xUnit frameworks is popular and known to have a positive influence on software quality. However, IDE plug-ins are fairly rare. With good tool support writing and running unit tests can become more efficient and fun. Since xUnit frameworks share a common structure, a generic approach is feasible.
Fingers crossed.
Here's the abstract:
The goal of this project is support for xUnit frameworks in Kdevelop4. More specific: QtUnit, CppUnit, Check and PyUnit.
Automated testing with the aid of xUnit frameworks is popular and known to have a positive influence on software quality. However, IDE plug-ins are fairly rare. With good tool support writing and running unit tests can become more efficient and fun. Since xUnit frameworks share a common structure, a generic approach is feasible.
Fingers crossed.
Abonneren op:
Posts (Atom)
