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
> , where it will
> be visible in the patch tracker?
> 
> 
> 

Aha, a new system!
Best,
Paul.