[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