Re: safer way to use gnulib

[Michael Goffioul]

On Sat, Feb 20, 2010 at 5:51 PM, Jaroslav Hajek <address@hidden> wrote:
> hi all,
>
> apparently the gnulib portability library caused a lot of new
> portability problems for us. It seems that the way it works, i.e.
> redefining common names to rpl_ replacements, is just too intrusive to
> be safely used in C++.
>
> Resigning on using gnulib at all would be a step backwards.
>
> I think we should use gnulib in a much stricter manner. I suggest we
> create a library of replacement system functions, say, liboctsys, that
> will be written exclusively in C with using gnulib. libsysrep will
> define functions like
>
> octave_sys_open
> octave_sys_fnmatch
>
> etc. The important restriction is that we shall *NOT* include any of
> the gnulib replacement header files in any of the octave_sys header
> files. We shall also *NOT* use -I ./libgnu when compiling liboctinterp
> and liboctave.
>
> In cases where this would be needed (for instance when gnulib wants to
> redefine macros or structs) we shall resort to autoconf magic to
> extract this stuff from gnulib an insert it into octave_sys headers in
> a safe manner.
> This way we shall avoid random #defines for common names such as
> "open", "close", "sleep" or "round" leaking into our headers, which
> apparently can confuse not only Octave's code (where we can work it
> around) but also standard C++ headers (where we can't) or user C++
> extensions (where users will no doubt become quite unpleased).
>
> What do you think? It seems that in the current state of affairs
> gnulib actually makes Octave less portable than before.

Being directly affected by the gnulib-generated problems, I can only
be in favor of a cleaner way to handle this. But we'll have to identify
all headers that are only provided by gnulib on some platforms
that are included unconditionally in octave. One typical example is
sys/time.h.

Michael.