[ET Trac] [Einstein Toolkit] #136: Don't rebuild external libraries so often

[Einstein Toolkit]

#136: Don't rebuild external libraries so often
--------------------------+-------------------------------------------------
  Reporter:  eschnett     |       Owner:        
      Type:  enhancement  |      Status:  review
  Priority:  minor        |   Milestone:        
 Component:  Cactus       |     Version:        
Resolution:               |    Keywords:        
--------------------------+-------------------------------------------------

Comment (by knarf):

 The patch only handles the problem for one library. Most users would
 probably like to have this mechanism for all libraries at the same time,
 without having to specify a lot of installation directories.

 What about the following:
 within configs/ (or a new subdirectory of the main tree) we create (if
 requested) directories containing all build libraries of a given
 configuration. We also save the configuration file (also including options
 given on the command line) which was used for these there. Comparing these
 saved configuration files to the one of a currently being built
 configuration shouldn't be hard or take long. Thus, when building a new
 configuration, we could (if requested) look through these directories for
 a matching configuration file and if found, let the library scripts know
 about that directory as installation directory, and they can then decide
 to either rebuilt into there or just reuse it.
 One issue with that is to decide what should happen on a make -clean.
 Right now this also rebuilds the libraries, which is fine, as they are
 local to one configuration and do not affect others. We should probably
 still clean the libraries, accepting that this will potentiall affect
 other configurations as well. That shouldn't be too much of a problem, as
 the same configuration options /should/ result in the same library being
 built, but that might not always be the case - like after an update of the
 library itself.

 On a higher level this could even be done with thorns in theory. I am not
 suggesting this right now, just would like to note it. I say in theory,
 because in practice this will not work as there might be dependencies of
 thorns on each other, changing something if some other thorn is present in
 a configuration or not, e.g., through the include-file mechanism. We would
 have to look out for similar dependencies of libraries on each other
 though.

 All a user would have to do is to enable this mechanism with one
 directive. Once we tested this for some time I could even think about
 making this the default, but of course we shouldn't do that too soon.

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