Re: [PATCH] gnu: Add openfoam

[Paul Garlick]

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

Aha, a new system!

Best,

Paul.