Hello Ludo,


I think it might make sense to create a new “simulation” module, and
eventually move OpenCascade there as well, WDYT?

Sure.  I will create a new module and put the OpenFOAM package definition in there as the first one.

Some comments:



+    (build-system trivial-build-system)



Did you consider using ‘gnu-build-system’?  I think this would save
quite a few lines corresponding to the initial setup (set-paths, unpack,
patch-shebang, etc.), and also ensure that the final phases (strip,
compress-documentation, etc.) are run.  In addition you wouldn’t need to
list all the usual build inputs (GCC, Coreutils, Make, etc.).  WDYT?

I did consider both options, removing and modifying stages in the gnu-build-system or starting from scratch with the trivial-build-system.  I can give the gnu-build-system option a go, reverting to the trivial-build-system if the new attempt proves too troublesome.  

One aspect I will need to investigate in the gnu-build-system is using the "./Allwmake" command to trigger the build process.  In OpenFOAM, wmake is short for "wrapped-make" and the package has its own configuration step.  In brief, it has its own sequence and does not follow the standard "./configure && make && make install" steps.

Using the trivial-build-system the patch-shebang section is indeed a little extended.  I found this was necessary to avoid a failure of the patch-shebang command using a simple 'find-files "."' from top-level directory.  There is a scenario where sub-directories named '0', in the 'tutorials' directory, identified by the find-files command, being passed to 'patch-shebang', which should only receive files, not directories.  This causes 'patch-shebang' to stop and the build fails.



+		   )
+		 )
+       )
+     )



Please listen to what ‘guix lint’ has to say about these.  :-)

Interestingly, 'guix lint' let me get away with this without making comment.  However, I shall condense things accordingly in the new patch.


What about wrapping the resulting binaries so that they have
‘FOAM_INST_DIR’ set to %output?

In fact, FOAM_INST_DIR is used in multiple places to navigate around the installed files (not just the binaries), so I think this variable may need to remain available as is.



You could make it “if true”, thereby avoiding the need to define
$READLINE_ROOT.

Could you elaborate on this idea a little?  At the moment the test is "if file exists".


Could you send an updated patch to guix-patches@gnu.org, where it will
be visible in the patch tracker?

Aha, a new system!

Best,

Paul.