Re: qhull6 and octave

[John W. Eaton]

On 16-Dec-2011, Brad Barber wrote:

| By having qhull.h-deprecated, these users can rename the file to
| qhull.h, and continue without other changes.

If qhull.h-deprecated is the same file as libqhull.h and your intent
is that users will have to rename a file, then I still don't see the
point.  They can just as easily rename libqhull.h.

| >I also think it would be great if this level of detail was not exposed
| >to the user of qhull.  As a user, I don't really care how the memory
| >is allocated internally, so it would be helpful to not have to change
| >my program depending on how the qhull library happens to be compiled.
| 
| Fully agreed, but I don't see a way around it.  The problem is that there are 
two very different ways of using Qhull.  It is embedded in all of the code.
| 
| 1) static allocation of qh_qhT as the global variable 'qh_qhT qh_qh'.   
Fastest code, but complicates swapping between Qhull instances.

Maybe I'm missing something, but even if the allocation is static,
can't qh_qh be a pointer that is assigned the address of the global
static variable?

| The 'qh' macro allows either to be used, or any other convention (e.g., 
thread-local storage).       Unfortunately, modern linkers do not detect the 
conflict if a program uses one convention and the qhull library the other.  On 
hindsight, I should have defined distinct names instead of qh_qh.
| 
| There does not appear to be a way to determine how qh_QHpointer should be 
defined.    You could have a flag file that indicates qh_QHpointer, but it 
wouldn't work for builds that need to create the various renditions of Qhull.   
Something like this may be a good idea for Octave and F, but I think picking 
one choice would be best.
| 
| My current plan is to ship builds that include all of variations -- static 
with and without qh_QHpointer, and dynamic with and without qh_QHpointer.  
Builds include Makefile, simplified Makefile (libqhull/Makefile), CMake, 
VisualStudio, and Qt.

That doesn't really solve our problem.  We (the Octave project) don't
build qhull.  We use whatever is installed on the system.  So we have
to be able to adapt to the way the installed version of qhull was
compiled, and we'd like for Octave to work with any version of qhull
that happens to be installed.  We want to do that by compiling a
program to test whether the library is available and how it was
configured.  If necessary, we can also run the test program, but that
causes trouble if we are cross-compiling Octave, since in a typical
cross-compile build we can't run a test program.

jwe