[ET Trac] [Einstein Toolkit] #1568: Reduce overhead of Formaline

[Einstein Toolkit]

#1568: Reduce overhead of Formaline
--------------------------+-------------------------------------------------
  Reporter:  hinder       |       Owner:                     
      Type:  enhancement  |      Status:  new                
  Priority:  major        |   Milestone:                     
 Component:  Cactus       |     Version:  development version
Resolution:               |    Keywords:                     
--------------------------+-------------------------------------------------

Comment (by knarf):

 For personal use, I would probably always use the "tarball" option. Local
 changes, local unpushed commits and whatnot would be not easy to include,
 and I don't usually see the tarball creation as too slow - my personal
 experience. What I do see is that Formaline includes some build-id into
 the executable, which forces a new link every time I rebuild Cactus, even
 if nothing else changed. If nothing else changes I don't see why Formaline
 should use a new build-id, and force a new linkage stage, and the
 executable updated.

 Another issue I have (had) was that (gnu) tar complains if files changed
 while processing them. A change in atime also counts as change, and this
 can happen when things are compiled in parallel. We don't care about the
 atime, so this isn't a problem, but these messages are annoying
 regardless. I am not aware of an option to tar to prevent this. The only
 way I currently see to avoid this entirely would be to make a copy before
 using tar, but that would be unacceptable performance-wise. On the other
 hand, I currently don't see this myself anymore on my development machines
 because I mounted my local file systems with "relatime" - access time
 changes are "almost ignored" on a file system level.

 Besides these two points (of which really only the first bothers me), I am
 currently quite happy with Formaline. It has "issues" from time to time
 (like every code), and usually they are fixed quite quickly.

 Roland: your code would put all data into one source code to be compiled.
 I believe this fails on several machines because that gets too large,
 which is why we have to split up some of the larger thorns into several
 'source C files' to be compiled and combined on a C-level.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1568#comment:5>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit