[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 bmundim):

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

 The patch is easy and simple enough to be ported to all other libraries,
 and I volunteer to do so if it is the case. I disagree it is a lot of
 installation directories. Right now the default in a .cactus/config
 file is to have this to force a library building:

 GSL_DIR = BUILD

 I propose to allow an extra option (that would add one *optional* line
 to each library line in the configuration file):

 GSL_DIR = BUILD
 GSL_INSTALL_DIR = /home/me/local/intel11/gsl-1.14.etc

 I mean there is even no need to have it there. If the library is not found
 in the system it is built and installed in the config/scratch directories.
 My suggestion doesn't change this behaviour, it only adds an option: to
 free
 the user to install the libraries where he or she wants to. The external
 libraries have nothing to do with Cactus and it doesn't make sense to me
 to bury them in the Cactus tree. The only advantage of using Cactus to
 build
 the external libraries is that Cactus know how to do so, as once Erik
 said.
 The user may want to use these libraries with other pieces of software or
 he/she may just not be willing to build libraries whenever a new
 configuration
 is created or an old one cleaned. There is no such an urgent need to do
 so,
 and, besides, we may inadvertently erase configs or whole Cactus trees
 without remembering that the libraries were buried there. So I think
 we should at least to provide a way out of this, and the simplest way
 I thought so far was to let the user especify the library installation
 directory.


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

 Your suggestion may improve things a bit re the frequency in which the
 libraries are built, but still doesn't give the user the freedom where
 to install the external libraries, it only changes the current default
 installation directories. These libraries would still be inside
 Cactus/configs tree.

 Concerning make -clean we could add an option to make libraries-clean or
 similar.

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