| Thread Previous • Date Previous • Date Next • Thread Next |
Johan Hoffman wrote:
I think so. I don't think a special --disable-modules will be necessary. But we will need the following targets: make modules make modules_install Then if one likes, one may enter into src/modules/demo and do makeSounds good.
Sounds good to me too.
One problem I have is that just moving demo, bench, test for modules into src/modules makes a very flat structure, with navierstokes at the same level as the demo for navierstokes. Perhaps we could have src/modules/ src/modules/solvers src/modules/solvers/navierstokes src/modules/solvers/elasticity src/modules/solvers/plasticity src/modules/demo src/modules/bench src/modules/test This could open up for creating other kinds of modules that are not necessarily solvers.The modules seem not that specified right now, and naming a module after a certain equation may not be that good, for example since a typical module may be multi-physics based, or several methods may be used for solving the same equation. Also, I do not think the /modules/solvers level is needed, it should be enough with /modules. And I'm not sure that we need to have a separate level for classifying the type of modules either (flow, solid, etc.) I think we should have src/modules, where we today can put modules that are maintained (navierstokes, elasticity,...), in a flat structure, and the naming could be quite free: "fluid-structure-interaction-solver", "fsi-flash", "heart", or whatever reasonable (where maybe not *-falsh would qualify...).
I would like to introduce some structure just to keeps things looking tidy. I don't mind categorising modules (flow, solid, etc). Rearranging is only a question of "mv". To me it's just important that the modules remain bundled together.
Garth
/Johan/Anders On Tue, Dec 05, 2006 at 01:50:00PM +0100, Garth N. Wells wrote:Did we reach a consensus on moving everything module-related (including module demos) to /src/modules/ and adding a make target "make modules"? Garth Johan Jansson wrote:I've created a branch of DOLFIN called DOLFIN-stable. Since every repository (every time you clone for example) is also a branch, this is nothing dramatic. The only difference is that this branch is publically available in the same way as DOLFIN is. The purpose of this branch is to keep the kernel stable. The only kernel changes allowed are backports of bugfixes and possibly important overlooked functionality from the DOLFIN repository. However, module changes are allowed as before. Kernel development is supposed to happen in the DOLFIN repository (where applications need to be stable to test the kernel) and application development is supposed to happen in the DOLFIN-stable repository (where the kernel needs to be stable to test the application). At regular intervals (at least at DOLFIN releases), the DOLFIN and DOLFIN-stable branches will be merged. Thus the DOLFIN and DOLFIN-stable branches will be equivalent at the time of every release. If the modules/applications are eventually detached into a separate repository, then the dual purpose of DOLFIN-stable might not be necessary any more. Johan _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev_______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@xxxxxxxxxx http://www.fenics.org/mailman/listinfo/dolfin-dev
| Thread Previous • Date Previous • Date Next • Thread Next |
