[Dune-devel] [Dune] dune & cmake

[Martin Nolte]

Hi Steffen,

I do not see this as a massive change. The most important point of removing the 
have/enable-trick is already being taken care of.

For libraries like SuiteSparse or SuperLU, we have to perform a library call 
anyway (which is usually quite expensive). Migrating the call into a dune-istl 
lib will not have a negative impact on the code.

For MPI, there is a real problem. All libraries using MPI must be compiled 
against the same version of MPI. But this problem already arises for our own 
depencies, like ParMETIS. If you compile ParMETIS with OpenMPI and DUNE with 
MPICH, you will end up in big trouble. Therefore, I think we should keep MPI our 
of this discussion.

But, yes, there is this very important point of DUNE being a header library in 
large portions of the code. This is quite incompatible with the normal approach 
of hiding configuration options in your library and exporting a single 
interface. On the other hand, if you look at standard header-only libraries, 
they will usually require you to always install all their dependencies and make 
sure you link against them - no configuration necessary.

My conclusion is this: We should try to hide as many configuration options as 
possible in our libraries. Where this is inapplicable, we should think about 
ways to circumvent user-defined preprocessor defines. For example, we do not 
need the define HAS_ATTRIBUTE_DEPRECATED_MSG. It can also be inferred from the 
gcc or clang version. If we don't know a compiler, we can safely assume it is 
not present. Such a change is local to dune/common/deprecated.hh, so it is not a 
massive change.

But the most important thing: I consider this merely a guide line. We should not 
start to change all of DUNE, now. Instead, whenever we refactor code containing 
configuration defines that can also be handled in another way, we should go for it.

Best,

Martin

On 04/20/2016 03:29 PM, Steffen Müthing wrote:
>
>> Am 20.04.2016 um 11:27 schrieb Andreas Dedner <a.s.dedner at warwick.ac.uk>:
>>
>>
>>
>> On 20/04/16 10:22, Robert Kloefkorn wrote:
>>> Then, miraculously, all would use the same
>>> config.h and nobody would ever complain about that.
>>
>> But only as long as you don't mix installed and non installed modules I
>> guess. That is the real issue isn't it?
>> Andreas
>
> As far as I understand, you get problems in general if you introduce inconsistencies
> into the configuration states of dependent modules, e.g. you compile your module
> with MPI enabled, but one of the modules you depend on was configured without MPI.
>
> The only way I see around that problem is to have each module generate its own "dune-xxx-config.h"
> that only contains the test results for the tests that were run in this module itself and that
> includes the "dune-yyy-config.h" files from all modules that it depends on. That makes it impossible
> to create inconsistent state (and also cuts down on configuration times because you don’t have to
> re-run tests that were already taken care off by another module somewhere up the stack).
>
> On the other hand, such an approach ties dependencies closer to the module that introduces them,
> even if the related code is header-only. A simple example: Right now, dune-istl itself does not have
> to depend on SuiteSparse or SuperLU, but if you install them separately, your own module can still
> use those libraries, even within code that is shipped as part of dune-istl (because it’s all just a bunch
> of headers).
>
> But switching to that approach might be worth it - it would, however, be a *massive* change…
>
> Steffen
>
>>
>> _______________________________________________
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>
>
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel
>

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany