mshr should be tested with assertions on on buildbots

[Jan Blechta]

Lot of times it happens that master either cannot be built with assertions or fails at runtime. Currently the failure is

[ 34%] Building CXX object CMakeFiles/mshr.dir/src/CSGCGALMeshGenerator3D.cpp.o
In file included from ../src/Polyhedral_multicomponent_mesh_domain_with_features_3.h:23:0,
                 from ../src/CSGCGALMeshGenerator3D.cpp:42:
../src/Polyhedron_utils.h: In static member function ‘static std::size_t mshr::PolyhedronUtils::remove_self_intersections(Polyhedron&)’:
../src/Polyhedron_utils.h:2504:18: error: ‘intersection’ was not declared in this scope
       dolfin_assert(intersection.size() == 0);
                  ^
../src/Polyhedron_utils.h:2504:18: note: suggested alternatives:
In file included from CGAL-4.6.3-installdir/include/CGAL/Constrained_Delaunay_triangulation_2.h:25:0,
                 from ../src/Polyhedron_utils.h:32,
                 from ../src/Polyhedral_multicomponent_mesh_domain_with_features_3.h:23,
                 from ../src/CSGCGALMeshGenerator3D.cpp:42:
CGAL-4.6.3-installdir/include/CGAL/Constrained_triangulation_2.h:1352:1: note:   ‘CGAL::intersection’
 intersection(const Gt& gt,
 ^
In file included from CGAL-4.6.3-installdir/include/CGAL/intersection_3.h:34:0,
                 from CGAL-4.6.3-installdir/include/CGAL/Kernel/function_objects.h:34,
                 from CGAL-4.6.3-installdir/include/CGAL/Cartesian/function_objects.h:28,
                 from CGAL-4.6.3-installdir/include/CGAL/Cartesian/Cartesian_base.h:68,
                 from CGAL-4.6.3-installdir/include/CGAL/Simple_cartesian.h:28,
                 from CGAL-4.6.3-installdir/include/CGAL/Exact_predicates_inexact_constructions_kernel.h:28,
                 from ../src/CSGCGALMeshGenerator3D.cpp:38:
CGAL-4.6.3-installdir/include/CGAL/Triangle_3_Triangle_3_intersection.h:173:1: note:   ‘CGAL::internal::intersection’
 intersection(
 ^

Could you turn the assertions on on buildbots, @johannes_ring, and reassign to @benjamik to solve the current issue?

[Benjamin Dam Kehlet]

Remove pointless assertion. Ref issue #34.

→ <<cset 3733862c7b35>>

[Benjamin Dam Kehlet]

Yes, the buildbots should of course build a debug build. Sorry for pushing premature code to master.

[Jan Blechta]

There's another one

[ 34%] Building CXX object CMakeFiles/mshr.dir/src/CSGCGALDomain3D.cpp.o
../src/CSGCGALDomain3D.cpp: In member function ‘void mshr::CSGCGALDomain3D::close_holes()’:
../src/CSGCGALDomain3D.cpp:1928:26: error: ‘{anonymous}::Exact_Polyhedron_3’ has no member named ‘is_close’
       dolfin_assert(impl->p.is_close());
                          ^
../src/CSGCGALDomain3D.cpp: At global scope:
../src/CSGCGALDomain3D.cpp:111:8: warning: ‘bool {anonymous}::polyline_is_degenerate(const std::vector<CGAL::Point_3<CGAL::Epeck> >&, double)’ defined but not used [-Wunused-function]
   bool polyline_is_degenerate(const std::vector<Exact_Point_3>& polyline, double tol)
        ^

[Jan Blechta]

Yes, the buildbots should of course build a debug build. Sorry for pushing premature code to master.

Maybe you would like to have next branch and run buildbots on it as well for experimenting...

[Benjamin Dam Kehlet]

I usually test feature branches on the buildbot (manually, by specifying the branch) before pushing. This time it was just laziness. (A next branch may be a bit overkill as long as I am the only one pushing code)

[Jan Blechta]

Ok.

[Benjamin Dam Kehlet]

I looks like mshr "inherits" the -DNDEBUG compiler flag from Dolfin through dolfin-config.cmake. (Which explains why I didn't see this on my machine, even when building in debug mode).

Is this a good thing? Is it a bad idea to to link a debug build of mshr with a release build of Dolfin? @johannes_ring any comments?

[Jan Blechta]

On my machine there appears -DDEBUG in CXX_DEFINES in <mshr>/build/CMakeFiles/mshr.dir/flags.make but not on buildbots. My suspicion is that it matters whether you have dolfin.pc in your PKG_CONFIG_PATH or configuring just from DOLFINConfig.cmake.

The most robust solution is modifying <mshr>/build/CMakeFiles/mshr.dir/flags.make by hand in case of troubles. Everything else very tedious to debug.

[Benjamin Dam Kehlet]

Ok, thanks! I will do that. But we should try to find a solution so that when -DCMAKE_BUILD_TYPE is given on the command line, it takes precendence over Dolfin's configuration.

[Johannes Ring]

I have configured the buildbot to build in debug mode by setting -DCMAKE_BUILD_TYPE=Debug. Anything else I should do?

[Benjamin Dam Kehlet]

Then hopefully it gets red now. Let's wait and see.

[Benjamin Dam Kehlet]

Hmm, looks like it compiled fine...

[Jan Blechta]

It's without assertions, check file /home/buildbot/buildslave/mshr-master-mpich/build/build/CMakeFiles/mshr.dir/flags.make on mpich buildbot.

/home/buildbot/buildslave/dolfin-master-full-mpich/build/build/dolfin/DOLFINConfig.cmake is with DEBUG and /home/buildbot/buildslave/dolfin-master-quick-mpich/build/build/dolfin/DOLFINConfig.cmake is with NDEBUG. That could be the difference.

[Benjamin Dam Kehlet]

Fix assertion statement. Ref issue #34.

→ <<cset 06d9342f27b6>>

[Johannes Ring]

@blechta - Yes, mshr was built against the quick DOLFIN build, which was built in Release mode. I have changed the build type now to Developer and mshr is now failing on one of the tests.

[Benjamin Dam Kehlet]

Good. I'll take a look.

[Jan Blechta]

Pathological inheritance of -D[N]DEBUG from DOLFIN filed as #35.