guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dave Love
Subject: [bug#28593] [PATCH] gnu: openfoam: Clean up to reduce closure.
Date: Wed, 27 Sep 2017 22:25:02 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Paul Garlick <address@hidden> writes:

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

That was confusing me too, and I was going to ask about it...

>> > +                      (zero?
>> > +                       (system* "find" "-name" "*.o" "-delete"))))
>> Rather:
>> 
>>   (for-each delete-file (find-files "." "\\.o$"))

I don't understand the need to avoid system(*), but I assumed the
optimizations in find make it significantly faster then find-files -- is
that not true?  (Dealing with the file structure in openfoam is horribly
slow when I've done builds on the NFS filesystems.)

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

Not in this case, but people have been using my rpm version in anger,
though it's an earlier version.  (I was looking at this partly to help
updating the rpm.)  I'd have expected to have to regenerate the
dependency files when modifying the source.

[I wish openfoam had a sane build system, even one that stopped on an
error, sigh.  Actually, it might be worth patching that, like the rpm --
I've several times missed components not being built -- assuming that
hasn't changed.]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]