[ET Trac] [Einstein Toolkit] #1769: External libraries: moving towards multiarch library directory structure

Einstein Toolkit trac-noreply at einsteintoolkit.org
Tue Nov 3 08:38:09 CST 2015

#1769: External libraries: moving towards multiarch library directory structure
  Reporter:  bmundim                |       Owner:                                  
      Type:  defect                 |      Status:  reopened                        
  Priority:  major                  |   Milestone:  ET_2016_05                      
 Component:  EinsteinToolkit thorn  |     Version:  development version             
Resolution:                         |    Keywords:  ExternalLibraries HDF5 Multiarch

Comment (by knarf):

 Replying to [comment:33 rhaas]:
 > They were developed on master, and my question is basically: if these
 changes were proposed (at the point in time of the last commit) for
 inclusion in the release, would you review them as "please apply"?

 I would. And of course they are developed for the development version.
 Where else would they be?

 > "development happens on master" and "changes to the ET require review",
 both of which we subscribe to.

 Indeed. This is a fine line to walk: as stable as possible, but without
 hindering progress.

 > Note that I am not suggesting at all to abandon the effort, I only want
 to check carefully whether we find it is in a state that is sufficient for
 the release.

 I agree with you. In order to provide a short-cut for others who do not
 want to read the entire thread I attempt a summary:

 Current state:
 - multi-arch libraries are now found, and correctly used, but only two
 libraries use this
   mechanism so far. More would be nice but has to happen after the
 release. No problems with
   that mechanism itself are currently known (to Frank).
 - In general, there exists a problem with Fortran modules in system
 include paths. This is
   independent of multi-arch, but happened to be found after the multi-arch
 change because Bruno
   both had the issue of multi-arch without pkg-config (ubuntu), and he
 uses the HDF5 Fortran
   bindings outside of the ET.
   The problem in short here is that in order to compile, the paths
 containing the Fortran
   modules have to be added to the INC_DIRS, but if these also contain
 headers from other
   libraries (as they often do for system paths) this may break other
 libraries. So, both
   adding and not adding them to INC_DIRS is problematic. Fortran module
 files should simply
   not be put in directories that contain also files from other libraries.
 Ideas for workarounds
   exist, but most are likely to invasive for the release.

   Frank thinks one of the following could be done about the Fortran module
 problem, if
   tested by someone who actually uses the Fortran bindings (again, nothing
 in the ET depends
   on them, so the ET itself will compile just fine):
   - Always build HDF5 if Fortran bindings are requested.
     This makes sure that the HDF5 library is in a location by itself. This
 is also a pretty
     small change. It would, however, build 'too often' in general. Frank
 could live with that
     for the release.
   - If Fortran is requested, add the HDF5 include directory, regardless
 whether this might be
     a system path or not. This is also a pretty small change in the
 script, but might break
     other libraries within the ET, on some machines. Frank thinks that
 this has the greater
     potential for breakage.

 In the long run we might just have to detect if the modules files are in
 an "inproper" location, and build ourself in that case.

Ticket URL: <https://trac.einsteintoolkit.org/ticket/1769#comment:34>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit

More information about the Trac mailing list