Re: [PATCH] gnu: Add openfoam

[Ludovic Courtès]

Hi Paul,

Paul Garlick <address@hidden> skribis:

>> 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.

Sounds good.

>> 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.  

With ‘gnu-build-system’ you’ll have to replace/remove some of the
phases, but hopefully it’ll be less troublesome nonetheless.

> 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.

‘find-files’ excludes directories by default, so it’s a little
surprising.  Anyway, we can surely find a way to work around the
problem.

>> > 
>> > +             )
>> > +           )
>> > +       )
>> > +     )
>> > 
>
>> 
>> 
>> 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.

Oh indeed, until now it would only scan 60 lines from the start of the
definition.  Fixed!

>> 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.

OK, though it would be good to make it work out-of-the-box when
FOAM_INST_DIR is undefined.

>> 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".

I was thinking about doing something like this:

-if [ -f /usr/include/readline/readline.h ]
+if true

and thus we wouldn’t need to define READLINE_ROOT, IIUC.

HTH,
Ludo’.