Re: confusing option name for wxWidgets configuration

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday, 07 August 2013, Mojca Miklavec wrote:
> On Wed, Aug 7, 2013 at 7:19 AM, sfeam (Ethan Merritt) wrote:

> all I'm saying is that it would be better to have the configure option
> names consistent with upstream wxWidgets (and possibly also more
> configurable, but I can live with what is there now).

I disagree. 
It makes more sense for gnuplot's own "configure" command
to be consistent with itself.  We already have

  --with-gihdir=DIR       location of .gih help text file
                          (default PREFIX/share/PACKAGE/VERSION)
  --with-ggi=DIR        enable the ggi driver (EXPERIMENTAL)
  --with-xmi=DIR        ggi's xmi support for pm3d (EXPERIMENTAL)
  --with-readline=DIR      specify the location of GNU readline
  --with-gd=DIR         where to find Tom Boutell's gd library
  --with-pdf=DIR        enable pdf terminal

I think it's reasonable that all the optional terminal drivers can
be selected by --with-XXX=DIR

Arguably it is confusing that for wxt  ./configure --help 
uses the word PATH rather than DIR:

  --with-wx-config=PATH   Use the given path to wx-config, the wxWidgets
                                           configuration program (default search in $PATH)

But it does say that the search is done in $PATH which should be a 
huge clue that it is talking about directories, not file names. 


>> The "official" options are:
>>     AC_ARG_WITH(wxdir,
>>                 [  --with-wxdir=PATH       Use uninstalled version of wxWidgets in PATH],
>>                 [ wx_config_name="$withval/wx-config"

Wait. Are you saying it would be better to have
   --with-wxdir=PATH
than it is to have the current
   --with-wx-config=PATH
??

I don't mind that, but either way it asks for a PATH not a filename.
And you'd still have to create the file $withval/wx-config


Finally, I don't understand why there is a problem having both versions
2.8 and 2.9 installed.  For better or worse (mostly the latter) OSX does
not have a system-wide ld.so.conf list of library paths, so there should not
be a problem that causes only one of the two versions to be found as
default by all programs.