[Dune-devel] [GSoC] Keep documentation up to date

[Christian Engwer]

Hi Miha,

I must push a little bit. There hasn't been much progress this week
yet. End of GSOC is approaching and we still have some important steps
to do.

What is the current state? YOur last blog entry is quite old and you
didn't post a recent status update on the list...
Please ask questions, otherwise we can not give help.

I'll try to look through your latest changes :-)

Ciao
Christian

On Thu, Aug 29, 2013 at 10:54:22AM +0200, Miha Čančula wrote:
> Yes, I probably should update it, now that the behavior is more or less
> fixed.
> 
> Unfortunately, I've been a little stuck on the buildsystem integration.
> This is necessary for getting the compiler and compile flags, and it's also
> more user-friendly. I imagined it like this:
> 1.) At configure-time, a configuration file (currently named "<name>.ini",
> can be changed if needed) is generated for each program you want to measure
> 2.) Additionally, a make target ("perftest_<name>") is created, so you can
> just call "make perftest_myprogram"
> 3.) There is another target, called just "perftest", which runs all the
> perftest_* targets it can find
> 
> Such a system seems quite reasonable for me, because most of the time the
> user will just call "make perftest" and be done with it. I implemented the
> exact same system in CMake. However, when I try to do the same thing using
> autotools, I can't seem to figure out how to do the first step. I have a
> template (perftest.ini.in), which I would like to replicate multiple times
> using ac_config_file(), but each time with different variables. Calling
> ac_config_file() and ac_output() multiple times in various combination
> doesn't work, it always uses the last values. You probably have more
> experience with autotools, is there an easier way to do it?
> 
> If there isn't, I can of course write another script (perhaps in Python)
> that generates the configuration file, but that would introduce even more
> complexity.
> 
> I had creating a single overview HTML file on the agenda for this week, and
> I think this would be easier, but I wanted to finish the buildsystem
> integration first. Due to the problems I think I'll do the overview first,
> update the documentation, and then try the buildsystem again.
> 
> 
> 2013/8/27 Christoph Grüninger <christoph.grueninger at iws.uni-stuttgart.de>
> 
> > Hi Miha,
> > could you be so kind and update the README, so that the barrier to test
> > your module is as low as possible? You should add that numPy is an optional
> > dependency, too.
> >
> > What's on your agenda for this week?
> >
> > Bye
> > Christoph
> >
> >
> > Miha Čančula <miha at noughmad.eu> schrieb:
> > > Hello, Christoph!
> > >
> > > I changed the behavior of the script, the argument should not be the
> > actual
> > > executable to run, but rather a configuration file that describes what to
> > > measure and some extra data. Try
> > >
> > > python3 perftest.py ../../src/dune_perftest_matrix.ini
> > >
> > > The configuration files are generated as part the build process, if you
> > use
> > > autoconf they're located in src, if you use cmake they're in
> > > build-cmake/src. You can alternatively call it by running 'make
> > > src/perftest_dune_perftest_matrix', or just 'make perftest'. The
> > generation
> > > of files is still not completely correct (you get some wrong names with
> > > multiple output files), but it should work.
> >

> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel


-- 
Prof. Dr. Christian Engwer 
Institut für Numerische und Angewandte Mathematik
Fachbereich Mathematik und Informatik der Universität Münster
Einsteinstrasse 62
48149 Münster

E-Mail	christian.engwer at uni-muenster.de
Telefon	+49 251 83-35067
FAX		+49 251 83-32729