location of hdf5 header files

[Ryan Schmidt]

On Oct 8, 2009, at 14:46, Darren Weber wrote:

> Firstly, it's a convenience.  When using ctags or any IDE system to  
> analyze a set of header files (for programming autocompletion), it  
> is convenient to have the headers in a package specific path within  
> the general ${prefix}/include path.  This is especially true for  
> large packages, like wx*, vtk*, InsightToolkit*, etc.
>
> Secondly, it's a safety-net.  At the very least, it is significant  
> and important that any headers located in the generic ${prefix}/ 
> include have some kind of unique naming convention, like a prefix in  
> their file name, to avoid any conflicts with other software  
> packages.  The hdf5 package appears to have  the file prefix of "H5"  
> to distinguish it from other packages.  However, a two-char prefix  
> is not exactly a reliable unique identifier, especially on a file  
> system that is not case sensitive.  To avoid potential conflicts  
> with other software packages, it may be preferable to locate the  
> headers within ${prefix}/include/hdf5/.  An additional layer may be  
> added by using ${prefix}/include/hdf5-${ver} where ver=1.6 (as of  
> the current writing, we have hdf5 @ 1.6.9).  The version specific  
> path should allow multiple versions of the library to co-exist in  
> the ports tree (in this regard, we have seen some issues with  
> versions of the hdf5 port in relation to the netcdf port).

For most ports, there's no need to install into directories whose  
names contain the version number, since there's no way to install  
multiple versions of a port and have them all active at the same time  
anyway. hdf could be an exception there, since we do have three hdf  
ports (hdf4, hdf5, hdf5-18).

In large part, the install location is up to the developer of the  
software. Developers can choose where they want their headers and  
other files to go. We can second-guess the developer, but we should  
carefully consider whether we know better than they do, and what  
problems such changes might cause. Any software that uses hdf would  
have to know where its headers are -- or use a pkg-config file or *- 
config program to find out, neither of which hdf appears to provide --  
so unless we install hdf in the usual place, we would also have to  
patch every other port in MacPorts that uses hdf. This may not be that  
many (I count 20 ports that depend on hdf4, hdf5 or hdf5-18) but it is  
something to consider.