From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 11 05:19:06 2017 Received: (at 28045) by debbugs.gnu.org; 11 Sep 2017 09:19:06 +0000 Received: from localhost ([127.0.0.1]:60493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drKrx-0003dt-Sz for submit@debbugs.gnu.org; Mon, 11 Sep 2017 05:19:06 -0400 Received: from smtp.hosts.co.uk ([85.233.160.19]:38178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drKrw-0003dN-4o for 28045@debbugs.gnu.org; Mon, 11 Sep 2017 05:19:04 -0400 Received: from [79.123.23.187] (helo=pancake.local) by smtp.hosts.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim) (envelope-from ) id 1drKrp-0007Wv-C6; Mon, 11 Sep 2017 10:18:58 +0100 Message-ID: <1505121536.2356.21.camel@tourbillion-technology.com> Subject: Re: [bug#28045] [PATCH] gnu: Add openfoam From: Paul Garlick To: Ludovic =?ISO-8859-1?Q?Court=E8s?= , Eric Bavier 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" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 28045 Cc: 28045@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --=-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--