From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dq5Ut-00044O-2g for guix-patches@gnu.org; Thu, 07 Sep 2017 18:42:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dq5Uo-0000Xw-2Q for guix-patches@gnu.org; Thu, 07 Sep 2017 18:42:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:46182) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dq5Un-0000XL-Ur for guix-patches@gnu.org; Thu, 07 Sep 2017 18:42:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dq5Un-00033O-LB for guix-patches@gnu.org; Thu, 07 Sep 2017 18:42:01 -0400 Subject: [bug#28045] [PATCH] gnu: Add openfoam] In-Reply-To: <20170811110636.23339-1-pgarlick@tourbillion-technology.com> Resent-Message-ID: Message-ID: <1504824095.3116.41.camel@tourbillion-technology.com> From: Paul Garlick Date: Thu, 07 Sep 2017 23:41:35 +0100 References: <1504818378.3116.38.camel@tourbillion-technology.com> Content-Type: multipart/alternative; boundary="=-PtzCJqg8wTB+pbqILHNk" Mime-Version: 1.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: 28045@debbugs.gnu.org --=-PtzCJqg8wTB+pbqILHNk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi Ludo, Thank you for your comments on the OpenFOAM layout. > > Would it be possible to follow a layout closer to what we usually do: There are some advantages of keeping the standard OpenFOAM layout, different though it is. Firstly, if it the layout remains upstream's responsibility it makes the Guix maintenance task simpler. Secondly, OpenFOAM users will immediately recognise the standard structure. > > Or perhaps there’s a middle ground we could find? Possibly but we would need to think of a way to avoid version clashes. One objective in packaging OpenFOAM for Guix is to allow users to have multiple versions of OpenFOAM installed at once. This is a common requirement in the OpenFOAM world since user development and upstream development are independent. However, it can be difficult to achieve, especially in a multi-user environment. Guix can offer an advantage over alternative methods of installation in this respect. To explain, imagine two OpenFOAM versions, A and B. If we use the OpenFOAM standard layout and install both with Guix we have: $GUIX_PROFILE/OpenFOAM-A /OpenFOAM-B A user might set up an alias to initialize the OpenFOAM environment variables for version A: $ alias startOFA='foamDotFile=$FOAM_INST_DIR/OpenFOAM-A/etc/bashrc; [ -f $foamDotFile ] && . $foamDotFile' Similarly, a 'startOFB' alias could be defined. The user could then choose the version for the particular task, or even use both versions simultaneously in separate shells. Could we achieve this versatility using a Guix-like layout? A possible problem might be executable files in version B clashing with executable files of the same name in version A, if they both share the $GUIX_PROFILE/bin directory. WDYT? Paul. --=-PtzCJqg8wTB+pbqILHNk Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit

Hi Ludo,

Thank you for your comments on the OpenFOAM layout.


Would it be possible to follow a layout closer to what we usually do:


There are some advantages of keeping the standard OpenFOAM layout,
different though it is.  Firstly, if it the layout remains upstream's
responsibility it makes the Guix maintenance task simpler.  Secondly,
OpenFOAM users will immediately recognise the standard structure.


Or perhaps there’s a middle ground we could find?  


Possibly but we would need to think of a way to avoid version clashes.
 

One objective in packaging OpenFOAM for Guix is to allow users to have
multiple versions of OpenFOAM installed at once.  This is a common
requirement in the OpenFOAM world since user development and upstream
development are independent.  However, it can be difficult to achieve,
especially in a multi-user environment.  Guix can offer an advantage
over alternative methods of installation in this respect.

To explain, imagine two OpenFOAM versions, A and B.  If we use the
OpenFOAM standard layout and install both with Guix we have:

$GUIX_PROFILE/OpenFOAM-A
                                  /OpenFOAM-B

A user might set up an alias to initialize the OpenFOAM environment
variables for version A:

$ alias startOFA='foamDotFile=$FOAM_INST_DIR/OpenFOAM-A/etc/bashrc; [
-f $foamDotFile ] && . $foamDotFile'

Similarly, a 'startOFB' alias could be defined.  The user could then
choose the version for the particular task, or even use both versions
simultaneously in separate shells.

Could we achieve this versatility using a Guix-like layout?  A possible
problem might be executable files in version B clashing with executable
files of the same name in version A, if they both share the
$GUIX_PROFILE/bin directory.

WDYT?

Paul.

--=-PtzCJqg8wTB+pbqILHNk--