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.


On Fri, 2017-09-08 at 22:30 +0200, Ludovic Courtès wrote:
Hi Eric,

Eric Bavier <ericbavier@centurylink.net> 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’.