On 5 January 2015 at 13:15, Garth N. Wells <[email protected]> wrote: > > On Mon, 5 Jan, 2015 at 11:35 AM, Anders Logg <[email protected]> wrote: > >> Regarding Git subtrees, would the idea be to create a new "super >> repository" named "fenics" and merge in all our packages as subtrees? >> > > I haven't looked at the details of subtrees, but it would be helpful to > have a system with a 'super-repository' that is made up of a collection of > sub-repos with independent history. > > Would developers then work mainly in the fenics super repository, which >> means we could have a single common script for local/debug/dev install? >> > > A single top-level install script is one possibility and would be helpful. > What I like a about the idea of a super-repository is that tracking down > bugs across packages by bisecting history history would be easier, and > users of the dev versions wouldn't have to worry about compatible > changesets across packages. > > I think the natural solution would be that subprojects have build scripts with the same interface, and the superproject has a build script that delegates to subproject scripts in a consistent way.
Currently I have all projects in a directory fenics/, and residing there is a script so I can write e.g. ./fenics fetch all ./fenics upd ufl ffc to have typical commands run in all projects. I think a simple script can give many of the benefits of a superrepo. And the main reason for using subtrees instead of just throwing all our >> packages into a common repository would be that we could still publish e.g. >> UFL as a stand-alone package with its own history? >> > > I think we concluded previously that it's important that project > repositories are also stand-alone (independent history, project-specific > pull request and bug tracking, although there is merit to consolidating > pull requests and bug tracking). > > Perhaps someone is willing to look closely at subtrees to see if it's > promising for us, and if it is then create an experimental super-repo to > play with? > > Garth > > > > -- >> Anders >> >> >> Mon Jan 05 2015 at 12:23:07 PM skrev Anders Logg <[email protected]>: >> >>> So if I understand correctly, instead of a script that builds locally in >>> each package directory, those scripts install everything to a common >>> configurable directory? Sounds useful. >>> >>> My thought was that when working on say UFL and FFC simultaneously, you >>> would source the generated local.conf from both those directories, but your >>> approach may simplify the workflow. >>> >>> I wouldn't mind following your approach in place of the one I suggested, >>> but perhaps both would be superseded by the use of Git subtrees as >>> suggested by Garth? >>> >>> -- >>> Anders >>> >>> Mon Jan 05 2015 at 12:07:59 PM skrev Martin Sandve Alnæs < >>> [email protected]>: >>> >>>> I like the principle but I don't quite get how this workflow handles >>>> cross-cutting simultaneous changes to e.g. ufl,ffc,dolfin. I currently >>>> handle that by having install scripts install to a directory chosen by an >>>> environment variable. >>>> >>>> >>>> I personally have local scripts called 'upd' under each fenics >>>> component so I can always build+install typing just ./upd. Some just call >>>> setup.py, while under dolfin 'upd' is a modification of cmake.local which: >>>> >>>> >>>> 1) Maps $BRANCH to 'master', 'next', or 'wip' for all other branches >>>> to avoid proliferation of build dirs eating disk space >>>> if [ "$BRANCH" = "master" ]; then >>>> BUILDBRANCH=$BRANCH >>>> elif [ "$BRANCH" = "next" ]; then >>>> BUILDBRANCH=$BRANCH >>>> else >>>> BUILDBRANCH=wip >>>> fi >>>> >>>> 2) Adds an environment variable to $BUILD (i.e. build.$BRANCH.$FENICS >>>> build.master.dev, build.master.py3) >>>> BUILDDIR=${PWD}/build.${FENICS_INSTALL_NAME}.${BUILDBRANCH} >>>> >>>> 3) Calls generate-all first if the $BUILD directory does not exist, >>>> making "rm -rf build.master; ./upd" produce a true clean build. >>>> Previous versions of cmake.local did this on first install, which is >>>> not sufficient. >>>> if [ ! -d ${BUILDDIR} ]; then >>>> time cmake/scripts/generate-all >>>> fi >>>> >>>> 4) Installs to a path taken from an environment variable (the setup.py >>>> based upd scripts also does this) >>>> INSTALLDIR=${FENICS_INSTALL_PREFIX} >>>> >>>> E.g. the UFL upd file contains: >>>> python setup.py install --prefix=${FENICS_INSTALL_PREFIX} >>>> >>>> >>>> Of course I can just keep making a modified local-install.sh if others >>>> don't agree with these changes. >>>> >>>> Martin >>>> >>>> On 5 January 2015 at 11:45, Anders Logg <[email protected]> wrote: >>>> >>>>> Hi, >>>>> >>>>> Here are some thoughts on a possible developer workflow (partly) based >>>>> on HashDist. >>>>> >>>>> The current HashDist-based installation (fenics-install.sh) seems to >>>>> work relatively well (yes there are bugs but Johannes has been very good >>>>> at >>>>> fixing them). Users and developers both can now easily build from source >>>>> an >>>>> entire FEniCS stack including both dependencies and FEniCS components. >>>>> >>>>> However, for developers that need to work on features/bugs for a >>>>> specific FEniCS package (say FFC or DOLFIN) it is less clear how to base >>>>> the workflow on HashDist. >>>>> >>>>> So, after some discussion with Johannes, here is a suggestion for a >>>>> common workflow (which not everyone needs to follow, of course, but >>>>> something I imagine would make life easier for many of us): >>>>> >>>>> 1. Users and developers alike build dependencies + FEniCS using >>>>> >>>>> fenics-install.sh >>>>> >>>>> 2. For each FEniCS-package, we add a script named >>>>> >>>>> local-install.sh >>>>> >>>>> For DOLFIN, we simply rename cmake.local --> local-install.sh and for >>>>> the other packages, we add a corresponding script which calls setup.py >>>>> with >>>>> the proper flags. >>>>> >>>>> 3. The script local-install.sh installs under local.$BRANCH and >>>>> generates a file named local.$BRANCH.conf that can be sourced. >>>>> >>>>> This way, one may have one or more HashDist profiles under ~/.hashdist >>>>> containing as many FEniCS stacks with deps as one needs, and for each >>>>> relevant package one is working on, as many local/branch builds as one >>>>> needs, and those development/debugging builds don't need to be installed >>>>> "system wide" (as in landing somewhere under ~/.hashdist), which means one >>>>> always has one or more working FEniCS stacks under ~/.hashdist for >>>>> production work. >>>>> >>>>> Would this be a good idea? Comments or objections? >>>>> >>>>> If there are no objections, I can make the required changes. >>>>> >>>>> -- >>>>> Anders >>>>> >>>>> >>>>> _______________________________________________ >>>>> fenics mailing list >>>>> [email protected] >>>>> http://fenicsproject.org/mailman/listinfo/fenics >>>>> >>>>> >>>> >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
