test python support
This is based on core/dune-common!960 (merged) It adds testing of the python bindings in different configurations. Also added tests for using an external builddir. To avoid increasing the number of pipelines these different setups are added to the existing pipelines. Six different configurations are tested (tensor product of (no python, internal venv, external venv) x (interbal builddir, external builddir)
Merge request reports
Activity
@simon.praetorius could you have a look please
82 out.write('{} {} {}:\n'.format(toolchain[0], toolchain[1], mod[0])) 94 extraTags = '' 95 if toolchain[2].get("python",None): 96 extraTags += " venv-" + toolchain[2]["python"] 97 if toolchain[2].get("builddir",None): 98 extraTags += " bdir-" + toolchain[2]["builddir"] 99 out.write('{} {} {}{}:\n'.format(toolchain[0], toolchain[1], mod[0], 100 extraTags)) 83 101 out.write(' <<: *{}\n'.format(mod[0])) 84 102 out.write(' image: registry.dune-project.org/docker/ci/{}\n'.format(toolchain[0])) 85 103 out.write(' variables:\n') 86 104 out.write(' DUNECI_TOOLCHAIN: {}\n'.format(toolchain[1])) 105 if toolchain[2].get("python",None) is None: 106 out.write(' DUNECI_CMAKE_FLAGS: "$DUNECI_CMAKE_GLOBAL_FLAGS"\n') 107 else: 108 # need to disable ALBERTA with python for now due to linker error -
Why does Alberta introduce linker errors? Can I inspect this somewhere? Do you get the same linker errors with the new
FindAlbertapackage, see core/dune-grid!484 (merged) ? I haven't really looked into this. There linker comes up with an
'undefined symbol: funcName'. It's an issue indune-py- perhaps some flags aren't correctly set there - but trying to figure out which symbolfuncNamecould be, was more then I cared to look into at the moment. I can try the branch you mentioned. It only appears with clang - gcc seems fine with everything I think.changed this line in version 3 of the diff
I've switched the toolchain in the dune-grid branch and the CI fails with the symbol issue https://gitlab.dune-project.org/core/dune-grid/-/jobs/240394 I tried if using PIC or shared libs makes a difference but it doesn't. The linker command is https://gitlab.dune-project.org/core/dune-grid/-/jobs/240447#L4178 and then importing it fails.
-
It is difficult for me to debug this. But, at least I know that
funcNameis some global static variable that is filled with the name of each called function using some macroFUNCNAME(...). It is defined in the utility librarylibalberta_utilities.so. This library should be linked when usingadd_dune_alberta_flags. Do you call this manually, or do you use something likeenable_all_packages? The latter should not work for alberta, since this library does not register dune package flags. The reason is that we need to know the dimworld in order to link the correct library. Maybe one could register the utility library only. The problem is that this is not accessible directly, since provided by pkg-config as dependency. Thanks, that helped me a bit. So we are using 'enable_all_packages'. The test where it is failing in the CI is actually compiling a YaspGrid but is linking against
/builds/core/dune-grid/build-cmake/lib/libdunealbertagrid*d.aand that see,s to be causing the problems. Settingadd_dune_alberta_flagswhen compiling yaspgrid doesn't seem to make sense. Btw: the problem is only with clang, thegcc 9-17passes with Alberta turned on.-
Actually, it not link against the
libdunealbertagrid*d.alibraries. This should only be done ifadd_dune_alberta_flagsis called. The problem is two-fold, I think: 1.libdunealbertagridis created usingdune_add_library. This adds the library toDUNE_MODULE_LIBRARIESthat is appended todune-grid_LIBRARIESin the correspondingdune-grid-config.cmakefile. 2. Somehow, all these libraries are linked by default. I have not yet found out why. It could be an effect of thedune_enable_all_packagesor of the way in dune dependencies are searched and included. You could check whetherDUNE_LIBSorDUNE_DEFAULT_LIBScontains thedunealbertagridlibraries. Another problem is the way the linker resolves symbols. Since funcName is actually not used, it should not be a problem. But somehow it is. That's the issue I really don't understand and of course might explain why gcc behaves differently from clang. Why it is working locally for me with clang is a further mystery...
mentioned in merge request !1 (closed)
mentioned in merge request core/dune-grid!484 (merged)
added 1 commit
- d1e17435 - adapt to change in default flags for python bindings
added 1 commit
- b154e2ff - [testing] make CI pass by disabling a toolchain for which numpy download fails
added 5 commits
- 7a811e2b - use the different images/toolchains to test different configurations of...
- 2bdaed45 - add gridtype selector to cmake flags to improve dune-fem testing
- 38bc18ad - [bugfix][alugrid] Allow debian:10 to fail.
- 47a47973 - adapt to change in default flags for python bindings
- 3347648d - do not force the 'overhaul' branch
Toggle commit listadded 1 commit
- 721c05f2 - need to use shared libs with clang for python bindings
mentioned in merge request core/dune-common!960 (merged)
added 1 commit
- 6f905532 - if dune-alugrid fails so does dune-fem so allow both to fail for now
added 1 commit
- 826f25a4 - if dune-alugrid fails so does dune-fem so allow both to fail for now
enabled an automatic merge when the pipeline for 19c4d741 succeeds
mentioned in commit 1f3fc1b8
