Re: OCTAVE_HELP vs HELP_OCTAVE

[Mike Miller]

On Thu, Feb 25, 2016 at 16:40:41 -0500, John W. Eaton wrote:
> On 02/23/2016 04:46 PM, Mike Miller wrote:
> >Recent changes have been removing conditionals in the public API and
> >changing how they are defined when needed. This is good progress.
> >
> >We now have a mix of macros of the form HAVE_OCTAVE_X and OCTAVE_HAVE_Y,
> >for example
> >
> >   HAVE_OCTAVE_DEPRECATED_ATTR
> >   HAVE_OCTAVE_GUI
> >
> >   OCTAVE_HAVE_FAST_INT_OPS
> >   OCTAVE_HAVE_SIG_JUMP
> >
> >Can we pick one of these? Personally I would prefer all public symbols
> >to start with OCTAVE_.
> 
> Yes, symbols that are used in the public header files should be defined in
> octave-config.h and start with the prefix "OCTAVE_".  These should be
> symbols that are either features that have been enabled or characteristics
> of the system that won't change.

Sounds good.

> But since the symbol in question is OCTAVE_DEPRECATED_ATTR, should we write
> 
>   OCTAVE_HAVE_OCTAVE_DEPRECATED_ATTR
> 
> ?

Or can we just remove it? Actually the only public HAVE_OCTAVE_foo macro
that is used anywhere is HAVE_OCTAVE_NORETURN_ATTR. Is F77_NORETURN()
useful outside of Octave? If not, I would also turn that into a private
symbol and drop all of the HAVE*ATTR macros from octave-config.h.

-- 
mike