all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dave Love <fx@gnu.org>
To: Paul Garlick <pgarlick@tourbillion-technology.com>
Cc: 28593@debbugs.gnu.org
Subject: [bug#28593] [PATCH] gnu: openfoam: Clean up to reduce closure.
Date: Wed, 27 Sep 2017 22:25:02 +0100	[thread overview]
Message-ID: <87ing3sukx.fsf@albion.it.manchester.ac.uk> (raw)
In-Reply-To: <1506426036.2423.32.camel@tourbillion-technology.com> (Paul Garlick's message of "Tue, 26 Sep 2017 12:40:36 +0100")

Paul Garlick <pgarlick@tourbillion-technology.com> 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.]

      parent reply	other threads:[~2017-09-27 21:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-25 10:44 [bug#28593] [PATCH] gnu: openfoam: Clean up to reduce closure Dave Love
2017-09-25 12:52 ` Ludovic Courtès
2017-09-26 11:40   ` Paul Garlick
2017-09-26 12:08     ` Ludovic Courtès
2017-09-27 21:30       ` Dave Love
2017-09-28  8:36         ` Ludovic Courtès
2017-10-02 20:41           ` Dave Love
2017-10-03 12:33             ` Ludovic Courtès
2017-10-07 20:45       ` Ludovic Courtès
2017-10-09 11:06         ` Paul Garlick
2017-10-19 11:06           ` Dave Love
2017-10-19 12:15             ` Ludovic Courtès
2017-10-20 10:32               ` Paul Garlick
2017-10-20 11:28                 ` Ludovic Courtès
2017-10-20 15:28                   ` Dave Love
2017-10-20 15:26                 ` Dave Love
2017-10-22 16:15           ` Dave Love
2017-10-23 15:00             ` Paul Garlick
2017-12-01 10:27             ` bug#28593: " Ludovic Courtès
2017-09-27 21:25     ` Dave Love [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ing3sukx.fsf@albion.it.manchester.ac.uk \
    --to=fx@gnu.org \
    --cc=28593@debbugs.gnu.org \
    --cc=pgarlick@tourbillion-technology.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.