location of hdf5 header files

[Jochen Küpper]

On 08.10.2009, at 21:46, Darren Weber wrote:

> On Thu, Oct 8, 2009 at 12:16 PM, Ryan Schmidt  
> <ryandesign at macports.org> wrote:
> On Oct 8, 2009, at 13:37, Darren Weber wrote:
>
> In cursory exploration of /opt/local/include/, it appears that many,  
> if not all, of the hdf5 header files are located at the root of /opt/ 
> local/include/.  Is that a mistake?  Should the hdf5 include files  
> get stored into something like /opt/local/include/hdf5/?
>
> Using "port contents hdf5 | grep \\.h$" I would agree that all this  
> port's headers are in ${prefix}/include. Is that a problem? Would it  
> be better to have them in a subdirectory? The port doesn't seem to  
> do anything to change the header location at present, so it just  
> installs them where the developer of that software thought they  
> should go. Is there a problem you're trying to solve by moving the  
> headers?
>
>
>
> Ah, it's not a current problem that prevents or interference with  
> other ports within MacPorts, ASFAIK.
>
> 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).

But you then have to teach your compiler where to find the headers  
individually for all these packets...  Software written for hdf5  
generally assumes that
   #include <H5...>
works and no
   #include <hdf5-1.x/H5...>
is necessary...

I think it's fine as it is, until there is a actual name clash.
Then it should be fixed upstream and all software has to be adopted to  
the new naming scheme...

(Just my 2ct;-)

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen-Kuepper.de
     Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
         Sex, drugs and rock-n-roll