Re: Configuration options [was: Policy question - to PM3D or not to PM3D?]

[Hans-Bernhard B. <br...@ph...>]

Petr Mikulik wrote:
> Candidates for being always in gnuplot are:

> #define EAM_DATASTRINGS 1
> #define EAM_HISTOGRAMS 1
> #define GP_MACROS 1
> #define GP_STRING_VARS 2
> #define GP_FIT_ERRVARS 1
> 
> They do not change "too many" places of the code.

Careful with this conclusion, please.  Changing few or many places of 
the code is only one side of the issue.  The other is possible 
incompatibility with existing user scripts.  That's e.g. why I made 
FIT_ERRVARS optional in the first place: it intrudes on the namespace 
for user-defined variables by creating new ones previous versions of 
gnuplot didn't touch.  Now that there's also "set fit noerrorvariables", 
this is no longer an issue, so this option can go away.

By the same reasoning, I'm quite sure it would be premature to make the 
string variables and macros stuff unconditional right now.  It would at 
least require a run-time switch that turns off all options that may 
break existing scripts, before the compile-time option can be disposed of.

> Next candidate is
> #define PM3D 1
> It appears in many places of the code, but anyway, I'm in favor to 
> remove this #define as well.

I'm not --- I still haven't fully given up revitalizing the 16-bit 
builds yet (I've got DOS16 to link with OW, a third-party linker and 
some serious modifications...). These 10 percent of extra load could 
easily kill those.

What might make more sense it so collect several existing options into a 
single new one.  I.e. PM3D could be subsumbed under the ancient "small 
gnuplot" option, #define LITE.  This won't make the source code any 
prettier, but reduce the complexity of the build process (less 
--enable/--disable switches in configure).