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
