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

[Christian Engwer]

Hi Miha,

> 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

The usual way to achive things like this with the autotools is to have
a make variable to choose:

e.g. "make perftest" which will loop through all tests
and  "make perftest TEST=foobar" which will only call the one test

This is used for example in the headercheck target (see
common/am/headercheck)

The other thing is that I don't think having one ini file per
application is very nice. It clutters our directories. As you already
decided to have the ini files instead of integrating the call directly
into the buildsystem, I would write just one big ini file and upgrade
the python script, so that you can run all tests or just one
individual test.

> 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

why do you need a temple? Is the user supposed to adapt the template?
Otherwise you could just write the ini file from scratch.

> 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.

As time is pressing I strongly suggest to have something which just
works and we can afterwards think about nicer solutions. Also, as you
currently have only cmake support, I can't help you at all. Do the
integration in _some_ way and then we can look into the details. I
think this should be possible in a short time, so that we can discuss
additional questions on monday. Once I know how things work in your
case I can help with the integration. But this is something I've been
stating for weeks now...

Christian

> 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