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:
Eric Bavier <firstname.lastname@example.org> 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.