From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drKsz-0001rj-VZ for guix-patches@gnu.org; Mon, 11 Sep 2017 05:20:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drKsu-0004Cw-VX for guix-patches@gnu.org; Mon, 11 Sep 2017 05:20:09 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:51813) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1drKsu-0004Ca-S6 for guix-patches@gnu.org; Mon, 11 Sep 2017 05:20:04 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1drKss-0003fG-ES for guix-patches@gnu.org; Mon, 11 Sep 2017 05:20:04 -0400 Subject: [bug#28045] [PATCH] gnu: Add openfoam Resent-Message-ID: Message-ID: <1505121536.2356.21.camel@tourbillion-technology.com> From: Paul Garlick Date: Mon, 11 Sep 2017 10:18:56 +0100 In-Reply-To: <87ingt9blp.fsf@gnu.org> References: <513001199.42346965.1504884898846.JavaMail.root@centurylink.net> <87ingt9blp.fsf@gnu.org> Content-Type: multipart/alternative; boundary="=-gvJ2Yb1oYg+2P4oz0zqe" 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: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Eric Bavier Cc: 28045@debbugs.gnu.org --=-gvJ2Yb1oYg+2P4oz0zqe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi Ludo and Eric, I think it is helpful to consider this question in two ways; thinking about the short term and the longer term.  I think in the short term it is best to stick with the OpenFOAM-standard layout, modified in the 'middle-road' way suggested earlier.  On top of the previous points made, there is an additional advantage to this approach in that the OpenFOAM-standard layout has been thoroughly tested in production use over many years. In the longer term I think it would be possible to develop a Guix- standard layout.  I cannot see any reason why this would not work.  However, with a large system such as OpenFOAM, this may not necessarily be an easy task.  I see this as principally an upstream job, since they are the most knowledgeable people on the current layout and are best placed to deal with any subleties involved.  With a working Guix package in place it will be a good time to contact upstream and discuss the merits of a new layout. Today I hope to finish the package definition.  I have placed the tree under the 'lib' directory and this allows the 'validate-runpath' phase to run.  The phase currently fails as ld-wrapper does not add the runpaths of the shared objects in the build tree.  I plan to use patchelf to fix this. Paul. On Fri, 2017-09-08 at 22:30 +0200, Ludovic Courtès wrote: > Hi Eric, > > Eric Bavier skribis: > > > > > It seems to me that if using Guix's profiles and environments, we > > could entirely do without OpenFOAM's installation directories and > > simply install into a standard bin/lib structure.  Just install > > libraries into (string-append %output "/lib") and the binaries into > > (string-append %output "/bin"). > Fair enough.  I guess the question is more whether (1) this would > work > :-), and (2) whether seasoned OpenFOAM users would be happy with > this. > > WDYT, Paul? > > Ludo’. --=-gvJ2Yb1oYg+2P4oz0zqe Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Hi Ludo and Eric,

I = think it is helpful to consider this question in two ways; thinking about t= he short term and the longer term.  I think in the short term it is be= st to stick with the OpenFOAM-standard layout, modified in the 'middle-road= ' way suggested earlier.  On top of the previous points made, there is= an additional advantage to this approach in that the OpenFOAM-standard lay= out has been thoroughly tested in production use over many years.

In the longer term I think it would be possible to develop = a Guix-standard layout.  I cannot see any reason why this would not wo= rk.  However, with a large system such as OpenFOAM, this may not neces= sarily be an easy task.  I see this as principally an upstream job, si= nce they are the most knowledgeable people on the current layout and are be= st placed to deal with any subleties involved.  With a working Guix pa= ckage in place it will be a good time to contact upstream and discuss the m= erits of a new layout.

Today I hope to finish the = package definition.  I have placed the tree under the 'lib' directory = and this allows the 'validate-runpath' phase to run.  The phase curren= tly fails as ld-wrapper does not add the runpaths of the shared objects in = the build tree.  I plan to use patchelf to fix this.

Paul.



On Fri= , 2017-09-08 at 22:30 +0200, Ludovic Court=C3=A8s wrote:
Hi Eric,

Eric Bavier <ericbavier@ce=
nturylink.net> skribis:



It seems to me that if using Guix's profiles and environments, we could ent=
irely do without OpenFOAM's installation directories and simply install int=
o a standard bin/lib structure.  Just install libraries into (string-append=
 %output "/lib") and the binaries into (string-append %output "/bin").



Fair enough.  I guess the question is more whether (1) this would work
:-), and (2) whether seasoned OpenFOAM users would be happy with this.

WDYT, Paul?

Ludo=E2=80=99.
--=-gvJ2Yb1oYg+2P4oz0zqe--