Re: Qhull include files

[Rik]

On 01/31/2012 06:18 PM, Brad Barber wrote:
> At 01:59 PM 1/31/2012, Rik wrote:
>> On 01/30/2012 09:09 PM, Tatsuro MATSUOKA wrote:
>> > Hello
>> >
>> > One thing I have to tell that directories of the header files of the
>> qhull 2012 are 'libqhull' and 'libqhullcpp' in the include directory.
>> >
>> > However, the octave assume that header files in the 'qhull'.
>> >
>> > I have copied libqhull to qhull in the build
>> >
>> > Regards
>> >
>> > Tatsuro
>> 1/31/12
>>
>> The Qhull include files have drifted around in the file system which is
>> why it is necessary when using Qhull2012 to either specify
>> '--with-qhull-includedir=DIR' or rename the libqhull directory to qhull
>> so that the build system can find them.
>>
>> From configure.ac, Octave is checking for Qhull in 4 places
>> [qhull/libqhull.h libqhull.h qhull/qhull.h qhull.h].
>>
>> --- configure.ac ---
>>
>> OCTAVE_CHECK_LIBRARY(qhull, QHull,
>> Â  [Qhull library not found -- this will result in loss of functionality
>> of some geometry functions.],
>> Â  [qhull/libqhull.h libqhull.h qhull/qhull.h qhull.h], [qh_qhull], [], [],
>>
>> --- configure.ac ---
>>
>> The resulting include file is similarly convoluted.
>>
>> --- oct-qhull.h ---
>>
>> #if defined (HAVE_QHULL_LIBQHULL_H) || defined (HAVE_QHULL_QHULL_H)
>> # if defined (HAVE_QHULL_LIBQHULL_H)
>> #Â  include <qhull/libqhull.h>
>> # else
>> #Â  include <qhull/qhull.h>
>> # endif
>> # include <qhull/qset.h>
>> # include <qhull/geom.h>
>> # include <qhull/poly.h>
>> # include <qhull/io.h>
>> #elif defined (HAVE_LIBQHULL_H) || defined (HAVE_QHULL_H)
>> # if defined (HAVE_LIBQHULL_H)
>> #Â  include <libqhull.h>
>> # else
>> #Â  include <qhull.h>
>> # endif
>> # include <qset.h>
>> # include <geom.h>
>> # include <poly.h>
>> # include <io.h>
>> #endif
>>
>> --- oct-qhull.h ---
>>
>> Qhull2012, using the cmake build and install instructions in the README,
>> installed the required header file in /usr/local/libqhull/libqhull.h.
>>
>> One option for Octave would be to add a fifth location
>> [libqhull/libqhull.h] to configure.ac.  In addition oct-qhull.h would
>> then need a third #elif branch to locate the necessary config files.
>>
>> However, I have a question about how downstream package maintainers
>> intend to treat Qhull.  They may decide to override the source code's
>> default install location and put the files in one of the existing
>> directories.  If they do that then a build on an ordinary system will
>> be fine.  I have CC'ed Jordi, who has experience with Debian packaging,
>> and Jussi, who has experience with Fedora packging, to get their opinion
>> on how the source code default paths and the distribution's default
>> paths interact and what the likely location of a Qhull2012 package would be.
>>
>> --Rik
>
> The qhull source tree was reorganized for 2011.1 to support multiple
> build systems  and the C++ interface.  I was following Qt convention. 
> They split up the headers into modules.
>
> In the code, there's multiple references to libqhull/*.h, especially from
> the C++ code to the C code.  This helps distinguish between C and C++
> headers.
>      #include "libqhull/qhull_a.h"
>
> The 'install' destination for include files was changed to reflect this
> organization.    It could be changed, at the cost of increasing the
> search paths for include files in the code.
>
> What is your preference?    If the qhull build can not use the installed
> 'include' directory, is that OK?

I think my preference is to wait for the package maintainers to weigh in on
this question.  Once we know where the include files will be we can code up
configure.ac appropriately.

>
> .../include/qhull/...  with C and C++ headers mixed together
>
> or
> .../include/qhull/libqhullcpp/... for C++ headers
> .../include/qhull/... with everything else
>
> or
> .../include/qhullcpp/...  with C++ headers mixed together
> .../include/qhull/...       with everythingelse
>
> or as is currently done:
> .../include/qhull/libqhull/...
> .../include/qhull/libqhullcpp/...
> .../include/qhull/road/...
>
> Can Octave simply upgrade to the current version?  Users should not be
> using qhull 2003.1 and 2009.1, especially as they move to 64-bit and
> larger memories.
Not always.  For example, sometimes users are on a Long Term Release of a
distribution which means the libraries are fixed except for security
patches.  Is there something glaringly wrong with earlier distributions,
like they add 2+2 and get 5, or is it performance-oriented like 64-bit
support?  Generally, Octave guru John W. Eaton frowns upon version checks
in the configure file.  Rather, it is usually preferable to test a library
for a specific functionality.  If it has the specific functionality we
need, even if other parts of the library are bad, then we will use it.

--Rik