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