gnuplot-beta

confusing option name for wxWidgets configuration

[Mojca M. <moj...@gm...>]

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. 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.

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. 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)

Thank you,
    Mojca

PS: I'm not requesting this for the 4.6 branch, but the trunk already
changed the option name(s) for Qt, so I don't find it so problematic
to also change the option name(s) for wxWidgets for the naxt major
release.

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

Re: confusing option name for wxWidgets configuration

[Mojca M. <moj...@gm...>]

On Wed, Aug 7, 2013 at 7:19 AM, sfeam (Ethan Merritt) wrote:
> 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.

It is what the help message says, but it's inconsistent with what the
upstream (wxWidgets) envisioned the option to mean.

>> 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.

To paraphrase: I had to go the extra mile and change the packaging of
wxWidgets to explicitly make that symlink. I thought that it would be
enough to specify the exact path, like:
    ./configure --with-wx-config=/opt/local/lib/wx/config/osx_cocoa-unicode-2.9
or like specifying things like
    MAKE=gmake
or
    EMACS=/some/weird/path/Emacs
where it doesn't really matter how the executable is called as long as
it's working.

>> 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.

Not really that different. It doesn't set any cflags/ldflags. It still
invokes wx-config for all the configuration.

> 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

That's not entirely true. Gnuplot contains m4/pkg.m4 for example,
m4/apple.m4 (that one doesn't come from any 'upstream' though) and
aclocal.m4 contains definitions like AC_DEFUN([AM_PATH_LISPDIR],...)

This is not another method of configuration. It only does things like

dnl WX_CONFIG_OPTIONS
dnl
dnl adds support for --wx-prefix, --wx-exec-prefix, --with-wxdir and
dnl --wx-config command line options

to make it easier to support flags like --with-wx-config (to find the
right wx-config) out-of-the-box and to make it easier to specify
things like
    WX_CONFIG_CHECK([2.5.3], [wxWin=1])
instead of this block for example:

    dnl Ckeck for wxWidgets version
    if expr 2.5.3 \> `${WX_CONFIG} --version` >/dev/null; then
      AC_MSG_WARN([Your development package for wxWidgets is too old,
you need at least version 2.5.3. The wxWidgets terminal will not be
compiled.])
      enable_wxwidgets_ok=no
    fi

All the compiler and linker flags would still work the same way as they do now.

> and I don't see any advantage over just invoking
> wx-config.

It's not a different method: wx-config would still be invoked and work
in exactly the same way. The advantage is that you could replace the
following code block in configure.in:

  dnl The user can specify another path for wx-config
  WXWIDGETS_PATH="${PATH}"
  AC_ARG_WITH(wx-config,dnl
  [--with-wx-config=PATH   Use the given path to wx-config, the
wxWidgets configuration program
    (default search in $PATH)],
    [ if test "${with_wx_config}" != "no" ; then
  WXWIDGETS_PATH="${with_wx_config}:${PATH}"
     fi ])

  dnl Look for wx-config in the path
  AC_PATH_PROG(WX_CONFIG, wx-config, no, ${WXWIDGETS_PATH})
  if test "${WX_CONFIG}" = "no"; then
    AC_MSG_WARN([wxWidgets can't be found. You can try
--with-wx-config-path to give the right path to wx-config. The
wxWidgets terminal will not be compiled.])
    enable_wxwidgets_ok=no
  else

    dnl Ckeck for wxWidgets version
    if expr 2.5.3 \> `${WX_CONFIG} --version` >/dev/null; then
      AC_MSG_WARN([Your development package for wxWidgets is too old,
you need at least version 2.5.3. The wxWidgets terminal will not be
compiled.])
      enable_wxwidgets_ok=no
    fi

    dnl Make sure we're using more than the 'base' wxWidgets. Those
    if expr `${WX_CONFIG} --basename` : '.*base' >/dev/null; then
      AC_MSG_WARN([You only have the 'base' flavor of wxWidgets. A
full wxWidgets library is required. On Debian/Ubuntu, please make sure
that you have a 'libwx...-dev' package other than just 'libwxbase-dev'
installed. The wxWidgets terminal will not be compiled.])
      enable_wxwidgets_ok=no
    fi
  fi

with maybe three or four autoconfig macro calls and offer the
packagers of gnuplot more flexibility and more standard options to
configure script.

>> 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.

There's no-one to report it to because I'm experimenting with the
packaging myself.

Off topic, but just to explain:

It's a horribly situation because version 2.8 doesn't compile on
recent macs at all (it only works up to Snow Leopard that has been
released four years ago, and even then it can only be compiled as
32-bit on a 64-bit machine which means that all of its dependencies
also need to be built as 32-bit), while a lot of developers of
wxWidgets-based software resist to support 2.9 (arguing that 2.9 is
experimental and that it should not be used - the truth is, 2.8 cannot
be used at all, so there is no choice).

Now, the package manager support systems ranging from Mac OS X 10.4
(officially 10.6) up to the latest versions. It supports x86_64, i386
(and unofficially also the ppc). And wxWidgets 2.8 work on 10.6.

So it makes it particularly useful if both wxWidgets 2.8 and 2.9 can
be installed side-by-side. Libraries and include dirs are already
different by default, so allowing a side-by-side installation
basically boils down to not installing ${prefix}/bin/wx-config for
both 2.8 and 2.9; wx-config cannot exist in PATH for both 2.8 and 2.9
at the same time.

> It's supposed to be there.  Here is a relevant link to
> the wx wiki:
>
>     http://wiki.wxwidgets.org/Wx-Config

But one cannot have both wx-config for 2.8 and wx-config for 2.9
active at the same time. So even when 2.9 is active, the package
manager needs to be able to compile packages against wxWidgets 2.8 and
in that case the package manager really needs to tell the configure
script how to configure for wxWidgets 2.8 without having the desired
wx-config in path.

In case of gnuplot I can do that now with
    ./configure --with-wx-config=/opt/local/libexec/wxwidgets/2.9
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).

Mojca

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.

Re: confusing option name for wxWidgets configuration

[Mojca M. <moj...@gm...>]

On Wed, Aug 7, 2013 at 7:22 PM, sfeam (Ethan Merritt) wrote:
> On Wednesday, 07 August 2013, Mojca Miklavec wrote:
>> On Wed, Aug 7, 2013 at 7:19 AM, sfeam (Ethan Merritt) wrote:
>
>>> 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
> ??

Yes.

Not for the reason of "more functionality", but for the reason of
better consistency with upstream wxWidgets.

> 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

Yes, I know. This is why I suggested to support both --with-wxdir=PATH
and --with-wx-config=FILE, but even if supporting both isn't
acceptable for gnuplot, it would still be better to have consistent
name.

> Finally, I don't understand why there is a problem having both versions
> 2.8 and 2.9 installed.

It's not a problem of not being able to have both installed at some
obscure location. But it's impossible to have wx-config installed for
both at default location.

On the link you gave me there's an example of using wx-config:
    g++ `wx-config --cxxflags` -o out *.cpp `wx-config --libs`

Say that "wx-config" points to the installation of version 2.9 (it
cannot point to both). On my machine wx-config --cflags returns the
following for example:
    -I/opt/local/lib/wx/include/osx_cocoa-unicode-2.9
-I/opt/local/include/wx-2.9 ...

If another package requires 2.8 and simply calls "wx-config" (as in
the example above) without letting the user configure where to find
wx-config, one simply cannot install that package without nasty
patches.

> 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.

I didn't understand that. (In case of gnuplot the library search path
is set by wx-config at compile time. Once the binary is compiled
against the right wxWidgets there are no problems any more. The only
"problem" arises when configuring/compiling software that depends on
wxWidgets.)

Mojca

Re: confusing option name for wxWidgets configuration

[Ethan A M. <sf...@us...>]

On Friday, August 09, 2013 01:46:57 am Mojca Miklavec wrote:
> On Wed, Aug 7, 2013 at 7:22 PM, sfeam (Ethan Merritt) wrote:
> > On Wednesday, 07 August 2013, Mojca Miklavec wrote:
> >> On Wed, Aug 7, 2013 at 7:19 AM, sfeam (Ethan Merritt) wrote:
> >
> >>> 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
> > ??
> 
> Yes.
> 
> Not for the reason of "more functionality", but for the reason of
> better consistency with upstream wxWidgets.

OK. Done.

	Ethan