[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#28593] [PATCH] gnu: openfoam: Clean up to reduce closure.
From: |
Paul Garlick |
Subject: |
[bug#28593] [PATCH] gnu: openfoam: Clean up to reduce closure. |
Date: |
Tue, 26 Sep 2017 12:40:36 +0100 |
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.