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
