Re: Cygwin compilation broken by bin_hook.c

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Sun, 3 Oct 2004, Daniel J Sebald wrote:
>
>  
>
>> (Either bin_hook.o is a replica of binary.o or it is empty, depending 
>>on a configure switch.)
>>    
>>
>
>That's terminally ugly.  We will have to find a better way of doing that.
>

I should say more.  I wonder if it is worth the effort to find a better 
way.  If there is one candidate of the "experimental" code that could be 
removed from the #ifdef's it may be the new binary construction, in 
which case gnuplot will no longer need the "binary.c" file; only 
bf_tests will.  Then there will be no need for this odd compilation.

There are elements of the binary code that are open for discussion, but 
since Ethan suggested de-entangling binary from "df_readline", I think 
something like

int
df_readline(double v[], int max)
{
    if (df_read_binary)
    /* General binary, matrix binary or matrix ascii
     * that's been converted to binary.
     */
    return df_readbinary(v, max);
    else
    return df_readascii(v, max);
}

is the way to go.  I think there is a big advantage to gnuplot, at the 
higher application level, having just one way to bring in data and not 
having to know if the data came from a binary file or an ascii file.  It 
cuts down some code (tradeoff the df_readbinary() routine for all that 
is in "binary.c".)  It enables 2D and 3D plots to be more similar which 
in the long run should prove beneficial.

If there are aspects of binary data that people think should still 
remain in the experimental realm, then move some #ifdefs around to 
isolate those elements, but leave the above construction so that 
"binary.o" is no longer necessary.  Just wait a bit so that everyone is 
comfortable with the new df_readbinary(), which is on by default.

Dan