[Dune] Globally installed modules vs. local modules

[Lukas Böger]

Hi Oliver and thanks for the fast reply!

The setup is as follows, globally installed in /usr:

* common, geometry, grid, istl, localfunctions, typetree, pdelab: 2.4.1
* dune-alugrid: 2.4.0
* dune-functions: 2.4-compatible
* ug: 3.11.0

though the last two shouldn't matter. I have an additional local folder
with

* common, geometry, grid, istl, localfunctions, typetree, pdelab:
  current master branch

When running

DUNE_CONTROL_PATH=`pwd`/dune-common/dune.module:`pwd`/dune-geometry/dune.module:`pwd`/dune-grid/dune.module:`pwd`/dune-localfunctions/dune.module:`pwd`/dune-istl/dune.module:`pwd`/dune-typetree/dune.module:`pwd`/dune-pdelab/dune.module
./dune-common/bin/dunecontrol --opts=options configure

with only the install prefix set in the options file, the cmake cache
cleared before and cmake of version 3.5.2, I get

Call Stack (most recent call first):
  cmake/modules/DunePdelabMacros.cmake:2 (include)
  [pwd]/dune-common/cmake/modules/DuneMacros.cmake:570 (include)
  [pwd]/dune-common/cmake/modules/DuneMacros.cmake:714
  (dune_process_dependency_macros)
  CMakeLists.txt:23 (dune_project)

CMake Error at /usr/share/dune/cmake/modules/Headercheck.cmake:11
(dune_common_script_dir):
 Unknown CMake command "dune_common_script_dir".
Call Stack (most recent call first):
  [pwd]/dune-common/cmake/modules/DuneMacros.cmake:738
  (setup_headercheck)
  CMakeLists.txt:23 (dune_project)

The problem here is that the global headercheck macro is found by cmake
instead of the local one in ./dune-common/cmake/modules, and those files
differ. More general, when I look at the cmake output, there are
several lines indicating that global files are invoked, e.g.

-- Performing tests specific to dune-common from file
/usr/share/dune/cmake/modules/DuneCommonMacros.cmake

The globally installed dune-alugrid module causes the inclusion of
global files here, as configuration works fine when adding dune-alugrid
to the local folder.

Best,
Lukas


On 27.06.2016 08:52, Oliver Sander wrote:
> Hi Lukas,
> 
> this should work, and I use this feature on a regular basis.  Nevertheless
> there may be bugs that may be triggered only by your particular setup.
> Can you describe on more detail what exactly you are trying to do?
> 
> Cheers,
> Oliver
> 
> On 24.06.2016 15:42, Lukas Böger wrote:
>> Dear all,
>>
>> is it generally discouraged to globally install a version of Dune
>> modules (e.g. stable 2.4.1) and then compile local versions besides
>> (e.g. current master branch)?
>>
>> While doing so with a set of local modules not matching the globally
>> installed ones, I ran into trouble with cmake modules. They were
>> globally found and their paths merged into CMAKE_MODULE_PATH in
>> dune_create_dependency_tree, such that they had precedence over the
>> local dune-common/cmake/modules directory with files of a more recent
>> version. I guess such a mix of global and local cmake modules of
>> different versions can work out by accident, but not in general.
>>
>> Example: globally installed dune-x, dune-y and dune-z (all 2.4.1) and
>> locally compile dune-x and dune-y (both current master branch), but
>> EXCLUDING the optional dune-z?
>>
>> Setting DUNE_CONTROL_PATH doesn't help here as global paths will be
>> searched for modules anyway.
>>
>> Best,
>> Lukas
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>