Subject: [Dorsal-dev] Simultaneous stable and devel builds

From: Harish Narayanan <[email-masked]>
Date: Wed, 03 Dec 2008 16:23:09 +0100

Hello all,

As I'm setting up a new machine, I'm looking to extend dorsal to work
cleanly with both stable and development versions of FEniCS projects
(simultaneously). I'm envisioning the user interface to look like:

./dorsal.sh [PLATFORM] [stable|devel]

where PLATFORM is automatically sniffed-out in case the first argument
is not provided (as it is now) and the build-system defaults to stable
tarball releases of packages in case the second argument is not provided.

I am envisioning package files to now look like (e.g., viper):

if [ ${DEVEL} == 1 ]
then
	NAME=viper
	SOURCE=http://www.fenics.org/hg/
	PACKING=hg
else
	NAME=viper-0.4.1
	SOURCE=http://www.fenics.org/pub/software/viper/v0.4/
	PACKING=.tar.gz
fi
BUILDCHAIN=python

where the DEVEL flag is suitably set to 0 or 1 based on what the user
wants. This is fairly clean.

Does anyone have any good ideas on optimally fetching and building
things, such that common dependencies go to a common build area, but
devel and stable versions of FEniCS projects go into separate locations
so they don't clobber each other?

Harish

---

From: Joachim Berdal Haga <[email-masked]>
Date: Wed, 03 Dec 2008 17:04:00 +0100

> tarball releases of packages in case the second argument is not provided.

An idea: Let the second argument not have any particular meaning, it's just a 
build name. Then, for a build with build name "stable":
- append "$INSTALL_PATH.stable" to PATH, LIBRARY_PATH etc.
For the package viper (as an example):
- source "viper.package"
- if "viper.package.stable" exists,
   * append ".stable" temporarily to INSTALL_PATH
   * source it
- if "viper.package.stable" does not exist, proceed as if no build name given.

I believe this is more flexible. You can for example handle older releases, 
including dependencies, by passing something like "v8.1" as the build name and 
creating *.package.v8.1 files.

> 	SOURCE=http://www.fenics.org/pub/software/viper/v0.4/

In the approach above, "viper.package" would be unchanged (or perhaps changed to 
point to the stable location), and "viper.package.devel" would have the lines:
   SOURCE=http://www.fenics.org/hg/
   PACKING=hg

-j.

---

From: Joachim Berdal Haga <[email-masked]>
Date: Wed, 03 Dec 2008 17:08:07 +0100

> - append "$INSTALL_PATH.stable" to PATH, LIBRARY_PATH etc.

sorry, "prepend".

-j.

---

From: Harish Narayanan <[email-masked]>
Date: Wed, 03 Dec 2008 17:14:04 +0100

Joachim Berdal Haga wrote:
> An idea: Let the second argument not have any particular meaning, it's
> just a build name. Then, for a build with build name "stable":

Yes, this will work. I hacked up something vaguely similar after
realising only problems seem to arise from the fastest changing packages
(dolfin, ffc).

> I believe this is more flexible. You can for example handle older
> releases, including dependencies, by passing something like "v8.1" as
> the build name and creating *.package.v8.1 files.
>
>> if [ ${DEVEL} == 1 ]
>> then
>>     NAME=viper
> In the approach above, "viper.package" would be unchanged (or perhaps
> changed to point to the stable location), and "viper.package.devel"
> would have the lines:

Yes, good idea (I think). I first misunderstood (I didn't note the
significance of the sourcing order) what you were trying to say and
wrote a big response, but this ought to do what I want it to.

Harish