[Dune-devel] [Dune-Commit] [Commit] dune-grid - 74c2f6b: [vtktest][fs1539] Add missing header.

[Jö Fahlke]

I originally thought about creating a shell script that runs first a c++
exutable to produce the file, and then a python script to check the file.
(That's how I would do it for autoconf -- for cmake you'd probably start both
the C++-part and and Python-part from cmake, sort-of what you describe, but I
haven't looked into that closely.)

There are a lot of problems with that approach:
* The test creates _a lot_ of vtk files, it probably has quite complete
  coverage of all the option combinations that you can have with the
  vtkwriter.  (It also does not choose totally unique filenames, so it
  overwrites some of the files it creates, but that could be fixed.)  How
  filenames are derived from from the name-parts is non-trivial and depends on
  both the dimension and whether you are using more than one rank.  Just
  extracting the filename from the VTKWriter and giving that to python seemed
  to be the simplest way.

* As long as we have both buildsystems, we should support both, including
  build trees both combined with and seperate from the source tree.  Using
  seperate shell and python scripts leads to the interesting problem that the
  script files are located in different directories from the compiled
  executables.  This means I have to do configure-substitutions in the shell
  script so it knows the build- and source-directories.  And I cannot even
  begin to imagine how to do this in the cmake-case.

  Running python from C++ and providing the python script as a command-line
  parameter just side-steps the whole issue, and I can run the test the same
  way I run any other test, no matter the build system.

The other way round, running the C++ executable from python, has similar
problems.  Plus, you need a configure-time test for python.

Now I agree that for a testing module, like the one you are working on, you
will probably have more cases like this, so it will pay to find a general
solution for situations like this.  And once you have it (and we are left with
only cmake, I don't think you want to invent a solution for autotools at this
point), feel free use it for the vtk test.

Regards,
Jö.

Am Mon, 16. Mar 2015, 11:19:54 +0100 schrieb Dominic Kempf:
> Date: Mon, 16 Mar 2015 11:19:54 +0100
> From: Dominic Kempf <dominic.r.kempf at gmail.com>
> To: "dune-devel at dune-project.org" <dune-devel at dune-project.org>
> Cc: dune-commit at dune-project.org
> Subject: Re: [Dune-devel] [Dune-Commit] [Commit] dune-grid - 74c2f6b:
>  [vtktest][fs1539] Add missing header.
> 
> Hey Jö, hey Dune list,
> 
> Doing a lot of C++/Python/CMake mixups in my work, I do not think it is the
> best solution to run python from C++. You could instead do a proper build
> system check for the python interpreter and provide a real python script
> under version control. The execution is then controlled by cmake, like this:
> 
> find_package(PythonInterp)
> add_test(${PYTHON_EXECUTABLE} myscript.py)
> 
> With this approach you have only gained that you are now running C++
> executables from python instead of the other way round. Still, you could
> completely separate the languages by having the test execute a subinstance
> of cmake in script mode which runs both the C++ and the pyhton parts and
> returns the test result. If you are interested, I can provide the
> implementation.
> 
> I do not think this is as that important for this task, but I wanted to
> initiate such discussion (because it will definitely come up again at some
> point).


-- 
Jorrit (Jö) Fahlke, Institute for Computational und Applied Mathematics,
University of Münster, Orleans-Ring 10, D-48149 Münster
Tel: +49 251 83 35146 Fax: +49 251 83 32729

Das Erststudium soll bis zum berufsqualifizierenden Abschluss
gebührenfrei bleiben, also bis zur Erlangung der Taxi-Lizenz.
-- Akrützel, Ausgabe vom 16.5.2002 (www.akruetzel.de)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20150316/759776aa/attachment.sig>