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

[Einstein Toolkit]

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

 Replying to [comment:28 knarf]:
 > > Anyways, I am reopening this ticket because the script is not able to
 find /usr/include/hdf5.mod which is in my system and hdf5 library
 installed does support fortran.
 >
 > Assuming this is Ubuntu (trusty, and for reference):
 > no pkg-config

 There is pkg-config installed on Ubuntu 14.04.3 LTS. I guess what you
 meant is that hdf5 doesn't have a *.pc on trusty, right?

 > {{{
 > /use/include/hdf5.h
 > /usr/include/hdf5.mod
 > /usr/lib/x86_64-linux-gnu/libhdf5.so
 > }}}
 >
 > The script (on my Ubuntu VM) finds hdf5.h and libhdf5.so. It never
 checks for hdf5.mod (only for the relevant libraries). It does search for
 the include path, and finds it as /usr/include. Because that is a system
 include path, it does not get added to the INC_DIRS, for the reason you
 stated. It goes on marking the library as found and starts to compile. It
 never fails since there is no Fortran HDF5 code in the ET.
 >

 That's true. It fails because one of our private codes use 'use hdf5'
 statement.

 > Now, gfortran decided to not search standard include paths when looking
 for .mod files (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707). This
 means, to get things to compile, you would have to add -I/usr/include -
 which obviously is a bad idea in general. That's why distributions started
 to put these into separate directories, which is the only sensible way -
 but doesn't help us here now. We cannot add /usr/include in INC_DIRS in
 case Fortran is requested, because that might just break the next library.
 We also do not sort the list of library/include directories according to
 their 'is system path' status for each compiler command. We probably could
 dabble into that mess - but is that what you want?

 One idea would be to define a new variable, let's say
 CCTK_APPEND_SYSTEM_LIBS_INCLUDES, and when set it to "yes" it would find
 out what the system library and include paths are and add them only after
 all libraries and flags have already been set. To avoid breaking other
 configurations this would default to "no". We could then play with it by
 setting to "yes" only on ubuntu.cfg and smooth the
 rough edges of the new system there.

 Also note that there is a discussion on standardize these new directories
 in the case of fortran:

 {{{
 https://bugs.linuxfoundation.org/show_bug.cgi?id=757
 }}}

 but progress is very slow on that matter.


 > One possible easier way would be to detect such situation, and to copy
 the .mod file to somewhere inside Cactus, and reference that path. This
 would separate the mod file from the system include path. But this would
 require checking that this file is always up2date with it's original
 location. We could use a symlink to make sure this is true, but would
 still need to check for it dangling.
 >

 ok, but I am not sure this would be a good idea. How would you check for
 that? What would trigger
 this checking?

 > In any case - I would like to see this issue with Fortran module files
 and standard include paths be rather in a new ticket, or things get too
 confusing here.
 >

 Ok, do you want to create a new ticket then?

 > > In addition your solution was applied only for HDF5 external library.
 There are others that need to be patched such as Boost, PAPI and pthreads.
 They were also moved to multiarch layout on ubuntu.
 >
 > Indeed. We didn't want to change all this for all libraries so short
 before a release. Eventually all libraries should use the flesh scripts.
 >

 Until then, I suggest to keep this ticket open. What do you think?

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