[Dune-devel] Regarding GSoC 2013

[Elena Petrevska]

Good day Mr. Engwer,

At first, thank you for your reply, it definitely helped me through to the
right things I have to put an accent on. On the other side, I apologize for
not responding yesterday, but the Hannover Messe (+ travelling to there)
took a lot from my time.

Anyhow, today I continue discovering more about dune and the dune-autobuild
tests. I also looked at this presentation of yours [1],  which gave me also
some insight about autobuild.


> We are currently using the automake test system to handle our
> tests. automake allows to specify applications to run as tests. These
> applications (and some further tests) are also run for our automated
> tests. Sadly the automated tests are currently in no good shape, but
> everybody can run the tests in his/her dune-src tree via the "make
> check" target.


I hope this will be the summer when the tests will be back into excellent
shape !

Regarding automake, I am reading through this book to get more familiar
with the tool [2].


> We currently do several different kind of tests:

 - unit tests:
>    test apps with hand-written unit test, no particular unit-test
>    library is used
>    (run via make check)
>  - buildsystem tests:
>    we have some minimal checks to ensure that all src files are
>    handled in the tar-balls and in the installation
>    (run via make sourcescheck)
>  - src consitency check:
>    headers should be self contained, thus we can test that every
>    header is in a shape that allows to compile it, especially this
>    means that all required headers are included. Some headers are not
>    intended as "interface" headers, so we can exclude these from the
>    test.
>    (run via make headercheck)
>  - system tests:
>    System tests allow to check the interplay of all components. This
>    is work in a relatively early stage. It is only available for
>    dune-pdelab and requires to write bigger
>    test-applications. Success/failure is detected by a fuzzy
>    comparison with reference data or reference logs.


Thank you for the detailed explanation of the way the tests are managed and
divided into parts.

>
> The architecture of the autobuild system is shortly described in
> doc/overview.tex in the dune-autobuild repo
> https://svn.dune-project.org/svn/dune-autobuild/
>

After having some small issues because of my proxy, I managed to cofigure
my svn settings so that to be able to copy the repository without any
problem. Now everything is set up for trying out and discovering in more
details how it functions.
I also am reading in this moment this manual about advanced bash
Programming [3], because in the README file it is said that one should read
about this topic. In addition, as you said, I went to the "overview.tex"
file and saw the way it works. Plus, I saw the images from the presentation
and knew I was on the right track :).


> I hopy this gives some first starting points. Feel free to ask further
> questions. I'll try to update the project description soon and add
> more details.


I will work this weekend on all things I mentioned, and inform you about my
progress as soon as the beginning of next week. I hope that is fine with
you.

Thank you very much for your guidance.

>
> > [*1*] https://live.gnome.org/GnomeWomen/OutreachProgram2012
>
> I remember having read some of your posts last year.
>

I was totally astonished when I read this last statement of yours ! It was
definitely one BIG Überraschung ! :)

Thank you once again,

Respectfully,
Elena Petrevska


[1] http://www.dune-project.org/publications/dune_autobuild.pdf
[2] http://www.gnu.org/software/automake/manual/automake.pdf
[3] http://tldp.org/LDP/abs/html/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20130413/44f2a70f/attachment.htm>