[bug#28593] [PATCH] gnu: openfoam: Clean up to reduce closure.

[Paul Garlick <pgarlick@tourbillion-technology.com>]

Hi Dave and Ludo,

Thank you Dave for your helpful suggestions on the OpenFOAM package
definition.

Firstly, on the question of adding a debug output, I have checked the
effect of the current '#:strip-directories' keyword definition.  In the
build log:

stripping binaries in "/gnu/store/4zqn4w0wlq0irdwh3dhrdbsr7i3f1dag-
openfoam-4.1/lib/OpenFOAM-4.1/platforms/linux64GccDPInt32Opt/bin" with
"strip" and flags ("--strip-debug" "--enable-deterministic-archives")
stripping binaries in "/gnu/store/4zqn4w0wlq0irdwh3dhrdbsr7i3f1dag-
openfoam-4.1/lib/OpenFOAM-4.1/platforms/linux64GccDPInt32Opt/lib" with
"strip" and flags ("--strip-debug" "--enable-deterministic-archives")

This suggests that the binaries in .../bin and .../lib are being
stripped.  However, if I check a randomly-selected executable in the
bin directory:

$ objdump --syms /home/paul/.guix-profile/lib/OpenFOAM-
4.1/platforms/linux64GccDPInt32Opt/bin/blockMesh | grep debug

0000000000000000       O *UND*	0000000000000000              _ZN
4Foam8fileName5debugE
0000000000000000       O *UND*	0000000000000000              _ZN
4Foam4word5debugE

The 'file' command also reports that the executables and shared objects
are 'not stripped'.  Does adding a debug output achieve the effect of
stripping the binaries? 

> 
> Normally the ‘strip’ phase would strip things.  I guess the problem
> here
> is that libraries are not in lib/, so nothing gets stripped.  This
> would
> be worked around by simply passing something like:
> 
>   #:strip-directories '("OpenFOAM-1.2.3/lib")

Would that not give a 'directory not found' message?  Currently,

#:strip-directories (list (string-append
                                  "lib/OpenFOAM-" ,version
                                  "/platforms/linux64GccDPInt32Opt/bin"
)
                                 (string-append
                                  "lib/OpenFOAM-" ,version
                                  "/platforms/linux64GccDPInt32Opt/lib"
))

> > 
> > +                  (add-after 'build 'cleanup
> > +                    ;; Avoid lots of junk installed
> > +                    (lambda _
> > +                      (delete-file-recursively
> > +                       "platforms/linux64GccDPInt32Opt/src")
> > +                      (delete-file-recursively
> > +                       "platforms/linux64GccDPInt32OptSYSTEMOPENMP
> > I/src")
> > +                      (zero?
> > +                       (system* "find" "-name" "*.o" "-delete"))))
> Rather:
> 
>   (for-each delete-file (find-files "." "\\.o$"))
> 
> Paul can you confirm that this is OK?
> 

Maybe.  We need to be careful that we not delete files which are needed
later on.  Typically, a user will copy part of the directory structure
to a subdirectory of $HOME and compile a new solver.  The OpenFOAM
'wmake' utility takes care of the dependencies and re-compiles object
files as needed.  

So, object files under 'platforms/linux64GccDPInt32Opt/src' should be
safe to delete.  However, this needs to be checked to make sure no
dependencies are deleted that cannot easily be re-compiled.  Have you
already checked this Dave by, for example, re-compiling a standard
solver?

Paul.