Re: confusing option name for wxWidgets configuration

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

On Sunday, 04 August 2013, Mojca Miklavec wrote:
> Hello,
> 
> Background: I've been working on a side-by-side installation of
> wxWidgets 2.8 and 2.9. The main problem on Mac is that wxWidgets 2.8
> cannot be compiled on operating systems newer than 10.6 (released 4
> years ago) and a lot of programs still don't support version 2.9. In
> such a scenario wx-config cannot be in path for both 2.8 and 2.9, so
> we need a way to specify which one to use.
> 
> When playing with configuration, the first thing I tried to do was
>     ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
> until I realized that gnuplot ignored this completely. Later I
> realized that --with-wx-config expects a *PATH* where an exacutable
> wx-config needs to be (no other name allowed), not the link to
> wx-config file itself. 

Yes.  That's what the help message says and what all the other
similar options require.

> So I created
> /opt/local/libexec/wxwidgets/2.9/wx-config with a symlink to the file
> mentioned above and now
>     ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
> works fine.

Yup.  That's the idea.  Except that you shouldn't have to create the
symlink yourself.  It should already be part of the distribution 
package for that version of wxwidgets.

> While the implementation in gnuplot is already a lot better than what
> the majority of software does, it's a minor inconvenience that the
> option name/meaning is different from the one officially provided by
> wxWidgets in the file aclocal/wxwin.m4 (see
> https://github.com/wxWidgets/wxWidgets/blob/master/wxwin.m4) and that
> one cannot use an executable with a different name. 

Well, no.  That's another method of configuration altogether.
Yes, we could in theory import or link to an *.m4 file and use that
during configuration.  But that's not the method used for other
gnuplot options and I don't see any advantage over just invoking
wx-config.

> The "official"
> options are:
> 
> AC_DEFUN([WX_CONFIG_OPTIONS],
> [
>     AC_ARG_WITH(wxdir,
>                 [  --with-wxdir=PATH       Use uninstalled version of
> wxWidgets in PATH],
>                 [ wx_config_name="$withval/wx-config"
>                   wx_config_args="--inplace"])
>     AC_ARG_WITH(wx-config,
>                 [  --with-wx-config=CONFIG wx-config script to use (optional)],
>                 wx_config_name="$withval" )
>     AC_ARG_WITH(wx-prefix,
>                 [  --with-wx-prefix=PREFIX Prefix where wxWidgets is
> installed (optional)],
>                 wx_config_prefix="$withval", wx_config_prefix="")
>     AC_ARG_WITH(wx-exec-prefix,
>                 [  --with-wx-exec-prefix=PREFIX
>                           Exec prefix where wxWidgets is installed (optional)],
>                 wx_config_exec_prefix="$withval", wx_config_exec_prefix="")
> ])
> 
> So instead of
>     ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
> I would expect either of the following options to work:
>     ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9/wx-config
>     ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
>     ./configure --with-wxdir=/opt/local/libexec/wxwidgets/2.9
> 
> I didn't try to research the history of this option in gnuplot. I only
> know that MacPorts tried to use
> --with-wx-config=/opt/local/bin/wx-config until now, but nobody
> realized that it didn't work. (It picked the right wx-config, but only
> because it was the first one in PATH, not because --with-wx-config
> would work the way the package maintainer imagined/expected it to
> work.)
> 
> My question is the following: would it be acceptable for gnuplot to either:
> a) [probably best option] include the official wxwin.m4 from upstream
> in its sources and call the few macros as documented in the link above
> (I can help with implementation and testing)
> b) change the option name and make sure that
> --with-wx-config/--with-wxdir would behave approximately the same as
> in upstream (as opposed to --with-wx-config behaving as upstream's
> --with-wxdir)

I would recommend reporting the lack of a file with the standard name
wx-config as a bug to whoever prepared your packaged distribution
of wxwidgets.   It's supposed to be there.  Here is a relevant link to
the wx wiki:

    http://wiki.wxwidgets.org/Wx-Config

		Ethan