Re: Symbols exported when TRACE not defined.

[Matt Rice]

On Sun, May 13, 2018 at 7:50 AM, Thomas Dickey <address@hidden> wrote:
> On Sat, May 12, 2018 at 06:41:42PM -0700, Matt Rice wrote:
>> The manual for the trace functions state,
>>
>> "These  functions are  normally  available only with the debugging
>> library e.g., libncurses_g.a, but may be compiled into any model
>> (shared, static, profile)
>> by defining the symbol TRACE."
>>
>> however the header file still appears to export these even when TRACE
>> is undefined. When working with a header file parsing FFI, this is
>> leading to the FFI generating a wrapper for the symbols, and then
>> eventually an undefined symbol reference unless
>>
>> would it be ok to avoid exporting these as well?
>
> yes/no:  I could ifdef-out the declarations when there's no TRACE,
> but since the same header files are used for normal/debug libraries,
> then that would make it unuseful.  I suppose I could introduce a new
> NCURSE_TRACE which developers would have to define to use the features,
> but it would be less impact if FFI could be told to check its results...

I will mull over writing a new tool for a bit,
it doesn't appear the one i'm using supports any postprocessing beyond
a regular expression matching header file names,
nor does it like preprocessed sources either,  and macros like
NCURSES_SP_NAME make plain text processing of the headers difficult,
apparently it extends beyond just the TRACE functions,

perhaps it would be less impactful to downstream users to declare them
unless told not to e.g.

#if NCURSES_NO_TRACE_DECLS == 0
extern ....
#endif

but the pattern of declare them unless this, don't compile them unless
e.g. TRACE is a bit odd, and perhaps confusing...

> By the way, we're discussing "declarations", not "exporting".
> Exports are done by the library, not the header-files.
> The header files tell what data-types to expect :-)

yeah, certainly was a poor choice of word