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.
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
