Re: compiling development sources

[John W. Eaton]

On 10-Feb-2010, Jaroslav Hajek wrote:

| I don't know, but I bet it's a violation of the C++ standard if
| <cstdio> includes some #define for fprintf, so that
| std::fprintf ultimately becomes std::rpl_fprintf (even if it actually
| worked). In C++, common identifiers can appear in multiple scopes, so
| if nothing else it's very bad manners for a C++ library to have such
| #defines.

I agree that it can cause trouble.  But I'm willing to put up with a
little trouble to have better portability provided by a library that
we don't have to maintain.  I really would prefer to avoid having
details like the implementation of the poll function for Windows
systems included in the Octave sources, so that become the maintainers
of it.  Those kinds of things should be shared by multiple projectspp
and maintained by the larger community, not by individually by every
project that needs them.

If there is a better way than gnulib that will provide a more complete
set of POSIX functions that we can work with, and that does not have
the kinds of problems that gnulib has, then I'm willing to at least
discuss the possibility of using it instead.

| If some of these leaks really can't be avoided, we should put
| somewhere a big fat warning "DON'T use" with a list of identifiers
| possibly broken by gnulib. I can easily imagine myself using an ad hoc
| variable called tms.

Ideally, I'd like to ensure that no Octave header that is installed
includes anything that defines a common name the way gnulib headers
do.  Realistically though, I'm not sure it is possible to eliminate
all of them.  Currently, Octave .h files include the following C++
versions of the C headers (the first column is the number of other .h
files that include the given header file):

     34 #include <cstdlib>
      9 #include <cassert>
      7 #include <cstdio>
      7 #include <cstddef>
      7 #include <cfloat>
      4 #include <climits>
      3 #include <ctime>
      2 #include <cstdarg>
      2 #include <cmath>
      1 #include <cstring>
      1 #include <complex>
      1 #include <cerrno>

and the following C-style headers:

     12 #include <sys/types.h>
      4 #include <windows.h>
      2 #include <sys/wait.h>
      2 #include <stdlib.h>
      2 #include <stdio.h>
      2 #include <signal.h>
      2 #include <OpenGL/gl.h>
      2 #include <GL/gl.h>
      1 #include <zlib.h>
      1 #include <unistd.h>
      1 #include <umfpack/umfpack.h>
      1 #include <umfpack.h>
      1 #include <uint8NDArray.h>
      1 #include <ufsparse/umfpack.h>
      1 #include <ufsparse/cs.h>
      1 #include <ufsparse/colamd.h>
      1 #include <ufsparse/cholmod.h>
      1 #include <ufsparse/ccolamd.h>
      1 #include <ufsparse/amd.h>
      1 #include <sys/stat.h>
      1 #include <sys/param.h>
      1 #include <sys/ndir.h>
      1 #include <sys/dir.h>
      1 #include <sunmath.h>
      1 #include <suitesparse/umfpack.h>
      1 #include <suitesparse/cs.h>
      1 #include <suitesparse/colamd.h>
      1 #include <suitesparse/cholmod.h>
      1 #include <suitesparse/ccolamd.h>
      1 #include <suitesparse/amd.h>
      1 #include <setjmp.h>
      1 #include <regex.h>
      1 #include <process.h>
      1 #include <ndir.h>
      1 #include <math.h>
      1 #include <hdf5.h>
      1 #include <ft2build.h>
      1 #include <fortran.h>
      1 #include <fftw3.h>
      1 #include <dirent.h>
      1 #include <dMatrix.h>
      1 #include <cxsparse/cs.h>
      1 #include <cs.h>
      1 #include <colamd/colamd.h>
      1 #include <colamd.h>
      1 #include <cholmod/cholmod.h>
      1 #include <cholmod.h>
      1 #include <ccolamd/ccolamd.h>
      1 #include <ccolamd.h>
      1 #include <base-list.h>
      1 #include <amd/amd.h>
      1 #include <amd.h>
      1 #include <OpenGL/glu.h>
      1 #include <GL/glu.h>

I don't know how many of these actually need to be included in .h
files.  For example, should a .h file include everything necessary for
it to be included and work in a .cc file, or should we expect that a
user of a .h file will have to include other headers first so that it
will work?  Whatever we decide about that, I think we may have some
work to do to clean things up so that we are more consistent in the
way things work.

But yes, even if we do some cleanup for the public interface to the
Octave internals (and maybe we should start thinking about actually
defining one) the problem is still there for any Octave source file
that could possibly include (even indirectly) a gnulib header file
that defines a symbol that you might want to use.

jwe