Sounds good. My suggestion based on this would be: 1. Look at subtrees. Any volunteers? I won't have time to dig into this at the moment but willing to help testing.
2. Add Martin's install script to all packages. Regarding 2: - The new script can be added alongside cmake.local for now - cmake.local can be removed when the new script works for everyone - The new script does not touch anything so it can be added at once (does not need to wait for release of 1.5) - The new script should generate some file that can be sourced to set environment variables - upd might be a good name for the script with upd.conf for the generated config file? Martin, could you add your script now, or send it to me for edit + add? (Part of the reason I'm pushing this is I want to look at a couple of issues, for which I need to rework my currently broken FEniCS build/config on my laptop.) -- Anders Mon Jan 05 2015 at 1:15:15 PM skrev Garth N. Wells <[email protected]>: > > 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
