Regarding Git subtrees, would the idea be to create a new "super repository" named "fenics" and merge in all our packages as subtrees?
Would developers then work mainly in the fenics super repository, which means we could have a single common script for local/debug/dev install? 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? -- 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
