<div dir="ltr"><div><div><div>Good Morning Christian, <br><br><blockquote>
please not so formal...<br></blockquote>I will give my best in adapting to this :).<br></div><div><br></div>These days, I was going through the syntax and the way of functioning of autobuild together with Dune. Please correct me if I am wrong, but this is what I realized, how it all functions. <br>
<br></div>So first of all, what I tried to do is to create some Makefiles inside the autobuild and somehow try to check how it works. It was unsuccessfully. The next time, I tried something different. Instead of trying to create new, I used the Makefiles in all dune- * module, which I previously copied to my pc, and run all tried all the tests you mention in one of the previous mails. Most of them passed, but sometimes it gave information that "a test was not run". From there, and from the presentation in the dune-autobuild/doc/overview (= the presentation I previously found in the "Publications and Talks") I could understand that actually every module has its own tests, separate from the others, which I found very practical and organized. So the user , using "<b><span style="font-family:courier new,monospace">make <check, sourcescheck, ...></span></b>" actually accesses the tests, whereas the dune-autobuild is the repository where the Build Clients input the tests to the Build server, so that the user can use it alone on her/his own desire. Thus, the user can run whichever test he wants and all the logs are saved on the pc, along the tests themselves. <br>
<br></div>Maybe I missed something, maybe I said something incorrect, but by writing this down in short what how I understood the concept of working, I would really like to insure my that I completely understood how dune, together with the dune tests, functions.<br>
<div><div><div><br><blockquote>sure... I have been discussing, what might be managable within one<br>GSoC project, this would be something you should think about as<br>well... we can then discuss this a little bit... it would also<br>
influence where to actually start.<br></blockquote>As first, you mentioned in one of the previous mails, that the automated tests are at this moment not in a good shape. I would really like to start there, by bringing them in a better shape. Still, these tests are from a enormous importance regarding the discovery of early problems in the code and gives more flexibility for changes in the future, which in my opinion, is of a gread importance.<br>
</div><div><br></div><div>On the other hand, I was thinking about possible ideas. I saw that in some of the modules, there are less tests than in some others. As an example, in dune-common and in dune-grid seemed to me that there were much more tests than in dune-geometry. I don't know what's the plan, but working with that type of modules where there are less number of tests, write some tests about them and then continue improving and writing more tests about the rest of the modules seems appropriate for me. My idea is that it is good for all of them should have adequate number of tests, enough for checking a big part of their functionality. <br>
<br>At this point, after reading your mail this morning, I started thinking of what tests I should include for the GSoC project, and how much time will be needed for making them, but also for afterwards, as I (even after GSoC, if there is a possibility) would definitely like to contribute to the project. <br>
<br>If you think I am wrong, or leading in a wrong direction, please,  do not hesitate to tell me. I would really like to hear whether I should 
change something in the direction that I've taken or the way I understood the concept. <br><br></div><div>Thank you in advance,<br></div><div>Regards, <br>Elena Petrevska<br></div></div></div></div>