location of hdf5 header files

[Darren Weber]

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

Take care,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20091008/e9a545a1/attachment.html>