[Dune] dune-alugrid / dune-grid
christoph.grueninger at iws.uni-stuttgart.de
Thu Apr 7 13:46:23 CEST 2016
we know that dunecontrol and the inter-modular dependencies are
difficult to handle. Thu current state is a result partly by history and
partly by need. Many projects of our size have quirky build systems.
Take for example OpenFOAM or FEniCS.
I understand that you think, you can do better. Especially for your own
project, where you can drop quite a lot of generality. Nevertheless,
you'll have to adjust your buildsystem part to all changes Dune will
see. In my experience, for the long term success of a code, it's better
to stick to upstream.
Am 07.04.2016 um 13:36 schrieb Martin Rückl:
> Hey Christoph
>> Have generate your own module with duneproject (from dune-common/bin)
>> at all?
> Yes, this is my old approach.
>> I don't get why you just use the build-system as we designed
>> it. Is there a problem, maybe we should fix it?
> I don't want to offense anyone, but to be honest: I don't like the whole
> duneproject/dunecontrol build system.
> I think I understand its usefulness for dune extensions, but my goal is
> to provide a project that uses dune as
> dependency. I REALLY want to spare my users (i.e. my boss) the fuzz with
> dune-control etc.
> Isn't this the whole idea behind tools like cmake: Having one common
> tool instead of a different build system for each dependency?
>> Well, we provide such files and we evalue them in every dune
> Great! Then I will have a look into these and try to figure out how to
> use them:-)
> I hope that clears up confusion :P
> Thanks Martin
The method has been developed for use on a high-speed electronic
computer and would be impractical for hand-solution purposes.
[Harlow & Welch 1965]
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Dune