fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.

--
Anders

Attachment: signature.asc
Description: Digital signature