On Tue, Apr 27, 2010 at 03:51:21PM +0200, Kristian Oelgaard wrote:
On 27 April 2010 15:34, Garth N. Wells<gnw20@xxxxxxxxx> wrote:
On 27/04/10 14:01, Anders Logg wrote:
On Tue, Apr 27, 2010 at 02:52:37PM +0200, Kristian Oelgaard wrote:
On 27 April 2010 14:18, Anders Logg<logg@xxxxxxxxx> wrote:
Any ideas on how to keep the code in the documentation and the actual
demos in sync? Should we have a script that copies all the source
files? Or should we do the opposite: extract the demos from the
documentation?
Good question, initially I thought copying from DOLFIN to documentation
was the way to go, but on second thought the other way around might be
better.
The reason is that if the demos break, then they will be fixed in the
documentation which makes is more likely that the accompanying text (and
code snippets) will also be corrected.
Kristian
Yes, that might be the best option, to have a script that generates
the tree of demos from the documentation.
Sounds a bit tricky with the revision control system as we have it now with
the demos as part of the DOLFIN code repository.
What we could do is move all the demos to the fenics-doc repository and
remove them from dolfin-dev. We could then follow the model that PETSc uses
for its build system and have scons download fenics-doc into the fenics-dev
tree upon build. For DOLFIN releases, we can copy fenics-doc into the
tarball.
fenics-dev or dolfin-dev? I agree that this approach sounds like the best option.
There is no dolfin-dev repository (I guess Garth means
dolfin-main). There is a fenics-dev repository (mainly containing the
common release script) but I don't think it is suitable for DOLFIN
demos.
Here's another crazy idea. How about throwing all the core packages
(DOLFIN, FFC, UFL, UFC, FIAT) into the same tree? The main advantages
would be removal of version incompatibility (and a more streamlined
user experience). The main disadvantage (the reason for having
separate projects in the first place) is it makes it difficult for the
developers of the different projects to make their own decisions and
develop in their own pace, but that might be less of a problem these
days when the same group of people are more or less maintaining all
packages.
