[Dune] State of source in executable

[Christian Engwer]

Hi Dominic,

> not sure whether this is what you are looking for, but I know that people
> use "supermodules" for that purpose. A super module is a repository, which
> has all the needed dune modules as submodules through the git-submodule
> mechanism. That way you can pin all the modules to specific revisions
> through commits in the supermodule. It doesnt handle uncommitted changes of
> course, but I would not recommend such a mechanism include those anyway.
> The approach is somewhat fiddly, but does not need support from the dune
> side at all.

There are different use cases. If you want to describe what in a paper
what someone else has to do to reproduce your results, it is not very
transparent to explain: checkout super module XYZ from my private
repository, but youd rather explain use DUNE version 2.5 + this tiny
patch and then checkout my module.

For your own work a supermodule is indeed a good way to deal with the
problem of managing the different dependencies. But even this has it's
downsides. The supermodule needs to be updated manually, when you
commit you recent changes, otherwise it will still point to the
previous version. So not really an ideal version.

Furthermore it is not easily possible to include the current state in
the results of you test run. You might want to archive your output
files. You module could automatically check the dependencies and log
the SHA and possible patches, but it can't know that there is a
supermodule. Obviously you could make this work for your private
setup ... log the SHA of the super module, but this will most likely
not for in general setting. Furthermore in my experience you are
playing around with different setups and will not immediatelly commit
each trial-and-error-change to you ini files, so a reference to the
particular SHA is not an option.

Ciao
Christian

> On Tue, Jun 27, 2017 at 3:01 PM, Christian Engwer <
> christian.engwer at uni-muenster.de> wrote:
> 
> > Hi Max,
> >
> > > I was wondering whether there was a dune-internal solution to have an
> > > executable report the state of its sources. I was thinking of some script
> > > that is called at compile-time through a macro (if possible) and exploits
> > > git functionality in the sense that it provides the SHA1-IDs of all
> > > dune-modules used as well as uncommited changes.
> >
> > we once had such functionality (in the time of subversion), but
> > oviously this does not work anymore. I also would like to have
> > something similar, in order to ease reproducibility of numerical
> > experiments.
> >
> > I would even suggest to include such functionality in dune-common
> > (once we have figured out how to do it properly...).
> >
> > First question would be, it is OK to limit ourselfs to git and
> > installed modules?
> >
> > Ciao
> > Christian
> >
> > _______________________________________________
> > Dune mailing list
> > Dune at lists.dune-project.org
> > http://lists.dune-project.org/mailman/listinfo/dune

-- 
Prof. Dr. Christian Engwer 
Institut für Numerische und Angewandte Mathematik
Fachbereich Mathematik und Informatik der Universität Münster
Einsteinstrasse 62
48149 Münster

E-Mail  christian.engwer at uni-muenster.de
Telefon +49 251 83-35067
FAX     +49 251 83-32729