gnuplot: update to 4.6.0

[mojca (Mojca Miklavec)]

I would like to request an update of gnuplot port.

I'm attaching a preliminary version of Portfile, however there are several caveats:

1.) I would like to see Qt terminal included. I didn't attempt to do that since I had problems with other issues. I'll try this later and it may be ignored for now.

2.) Current Portfile includes a not-so-relevant patch. I just commented it out for a moment (it can be included later and it needs to be adapted a bit to work with new version, I just wanted to sort out other issues first).

3.) I would like to see wxWidgets-devel (wxWidgets 2.9.x) being used to enable 64-bit application. I commented out the old code and wrote a new one using

variant wxwidgets description "Enable wxWidgets front-end" {
    depends_lib-append      port:wxWidgets-devel
    configure.args-delete   --disable-wxwidgets
    configure.args-append   --with-wx-config=${prefix}/bin/wx-config
}

however that part needs to be fixed by someone more knowledgable about variants than I am. For anyone using 64-bit Mac OS X, wxWidgets-devel should be the preferred option. For those who only need/want i386 and/or ppc, wxWidgets are probably just fine.

4.) I have a problem with wxWidgets. The file ${prefix}/bin/wx-config lists -framework QuickTime and that one generates

ld: warning: ignoring file /System/Library/Frameworks//QuickTime.framework/QuickTime, file was built for unsupported file format which is not the architecture being linked (x86_64)

4.) If I want to build wxWidgets, clang++ complains, while gcc (llvm-g++-4.2) works fine. It stops with (after manually removing QuickTime):

:info:build /usr/bin/clang++  -pipe -O2 -arch x86_64 -I/opt/local/lib/wx/include/osx_cocoa-unicode-2.9 -I/opt/local/include/wx-2.9 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__  -D_REENTRANT -I/opt/local/include/cairo -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/libpng14 -I/opt/local/include/pango-1.0   -D_REENTRANT -I/opt/local/include/gtk-2.0 -I/opt/local/lib/gtk-2.0/include -I/opt/local/include/atk-1.0 -I/opt/local/include/cairo -I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/pango-1.0 -I/opt/local/include/gio-unix-2.0/ -I/opt/local/include -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/libpng14    -L/opt/local/lib -arch x86_64 -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -o gnuplot alloc.o axis.o binary.o breaders.o color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.o getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3d.o readline.o save.o scanner.o set.o show.o specfun.o standard.o stats.o stdfn.o tables.o tabulate.o term.o time.o unset.o util.o util3d.o variable.o version.o wxt_gui.o gp_cairo.o gp_cairo_helpers.o   -lreadline  -lncurses  -lz -lgd -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng -lz -liconv -ljpeg -lfreetype -lpng -lpdf -L/opt/local/lib -llua -lm    -L/opt/local/lib   -framework IOKit -framework Carbon -framework Cocoa -framework AudioToolbox -framework System -framework OpenGL -lwx_osx_cocoau_xrc-2.9 -lwx_osx_cocoau_webview-2.9 -lwx_osx_cocoau_html-2.9 -lwx_osx_cocoau_qa-2.9 -lwx_osx_cocoau_adv-2.9 -lwx_osx_cocoau_core-2.9 -lwx_baseu_xml-2.9 -lwx_baseu_net-2.9 -lwx_baseu-2.9  -L/opt/local/lib -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl   -L/opt/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lgio-2.0 -lXfixes -lcairo -lX11 -lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl    -laquaterm  -framework Foundation -L/opt/local/lib -lz -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl  
:info:build Undefined symbols for architecture x86_64:
:info:build   "wxNavigationEnabled<wxNonOwnedWindow>::SetFocus()", referenced from:
:info:build       vtable for wxtFrame in wxt_gui.o
:info:build       vtable for wxtConfigDialog in wxt_gui.o
:info:build       vtable for wxMDIParentFrameBase in wxt_gui.o
:info:build   "wxNavigationEnabled<wxNonOwnedWindow>::AcceptsFocus() const", referenced from:
:info:build       vtable for wxtFrame in wxt_gui.o
:info:build       vtable for wxtConfigDialog in wxt_gui.o
:info:build       vtable for wxMDIParentFrameBase in wxt_gui.o

Does anyone have a clue what goes wrong with clang++?

[mojca (Mojca Miklavec)]

Portfile for gnuplot 4.6.0 (not finished yet)

[mojca (Mojca Miklavec)]

The following addition to the attached Portfile solves the problem with clang++ compiler, but it would still be interesting to figure out why the problems with compiler appears in the first place.

if {[variant_isset wxwidgets]} {
    if {${configure.compiler} == "clang"} {
        configure.compiler llvm-gcc-4.2
    }
}

[mojca (Mojca Miklavec)]

I also created another ticket for wxWidgets-devel to address issue nr. 3: #33597. I'm not sure whether we need a separate ticket about wxWidgets-related compiler issues.

[mojca (Mojca Miklavec)]

patch that enables horizontal scrolling in wxt terminal (already in gnuplot trunk, but not in 4.6.0)

[mojca (Mojca Miklavec)]

update patchfile (line offset); contents should eventually be sent to gnuplot dev team

[mojca (Mojca Miklavec)]

I wanted to add a comment about the following part in Portfile:

platform darwin {
    depends_lib-append      port:aquaterm
    configure.cflags-append -DDEFAULTTERM='"aqua"'
}

The second line is not needed, and - sadly enough - even ignored. See the rejected request at ​sourceforge.

At the moment there are 4 different usable terminals on Mac OS X: aquaterm, qt, wxt, x11. AquaTerm is a bit buggy and incomplete from the features point of view, Qt needs some additional patching, wxt and x11 seem to work fine. But as long as one has AquaTerm installed, there is currently no way to set any other terminal as default one (except via ~/.gnuplot file).

[mojca (Mojca Miklavec)]

A patch that enables compilation of Qt (one could create a cleaner patch and submit it upstream, but this should do the job)

[jpo@…]

Cc Me!

[kurtjaeke@…]

Cc Me!

[kurtjaeke@…]

Can't we just release gnuplot 4.6.0 without Qt, and work on the Qt Terminal in a revision bump? IMHO, it is much more important to see 4.6.0 in MacPorts at all initially before working on details.

Could we open separate bugs for all the other issues mentioned in the bug report and just move on to release 4.6.0 for the masses?

[kurtjaeke@…]

Portfile to upgrade to gnuplot 4.6, with only minimal changes.

[mojca (Mojca Miklavec)]

I'm all for updating Gnuplot to 4.6.0, but there was no feedback to my portfile so far. I mentioned all the issues, but most were related to the first gnuplot.Portfile and I gradually improved them in the second attachment.

The file gnuplot.2.Portfile together with attached patches works perfectly fine for me, the only question is whether (temporary) using Carbon framework and wxwidgets-devel is acceptable. Both wxwidgets-devel and qt are a bit better that AquaTerm and wxwidgets 2.8, so I would really like to see them included. Qt hasn't been included earlier, so even if it is still suboptimal, that shouldn't be a problem.

(The only component that I might have forgotten is adding -framework Carbon to LDFLAGS for Qt terminal, just in case. And as I already said, -DDEFAULTTERM='"aqua"' has no influence and could easily be removed, as you already did in GNUplot.portfile.)

Does it work for you to build qt and wxt terminals with my gnuplot.2.Portfile?

[kurtjaeke@…]

I didn't try. I upgraded only to get ​this bug fixed, because it breaks lua-tikz, which is what I use for my plots.

Making gnuplot depend on a "devel" port does not seem a good idea to me. "devel" ports may introduce disruptive changes in a high frequency, requiring somebody to clean up in this very frequency. MacPorts is about packaging and distribution, so the aim should be maximum stability. Therefore, even a hypothetical risk should be avoided IMHO.

As I proposed before: we should upgrade gnuplot to 4.6.0, and take care of the other enhancements in separate tickets.

[mojca (Mojca Miklavec)]

wxwidgets-devel is not upgraded on regular basis and is a bit painful either way. If nothing else, without "-devel" switch one cannot build 64-bit binary. But even if wxwidgets-devel is left out, I would make me really really really happy if Qt support could be added. May I ask you for testing my patch with +qt option or do you find it too painful to wait for compilation of qt?

[kurtjaeke@…]

Can we agree on upgrading gnuplot in the first place, and go on about the Qt terminal in another ticket? Having gnuplot 4.6.0 AT ALL in the first place would make me extremely happy, since it fixes a showstopper for me.

[mojca (Mojca Miklavec)]

(I can agree on anything, but this won't help until somebody with commit rights actually decides to commit a patch to the source and most likely he will be the one to decide what goes in.)

That said, I don't mind the order and I don't care if 4.6.0 is imported with qt right away or without qt first and then with qt patch a few days later.

But in both cases it would be nice if somebody else tests qt which is why I asked.

[mojca (Mojca Miklavec)]

Portfile for gnuplot 4.6, now with working Qt terminal

[ryandesign (Ryan Carsten Schmidt)]

I'll give your latest Portfile​ a try. For future reference, it's easier to review your proposals if you attach a unified Portfile diff instead of a complete new Portfile.

[ryandesign (Ryan Carsten Schmidt)]

I tested on Snow Leopard with Xcode 3.2.6. With default variants + universal it built fine. With default variants + universal + qt it failed with "qtterminal/qt_term.cpp:314: error: ‘kProcessTransformToBackgroundApplication’ was not declared in this scope". wxWidgets-devel is building now; will test gnuplot +qt later.

[mojca (Mojca Miklavec)]

patch for Qt against 4.6.0 (need a run of ./prepare first)

[mojca (Mojca Miklavec)]

I'm sorry, I'll add a unified patch next time.

Right now I was playing with Qt a bit more, but there are some confusing facts. I added ​gnuplot-qt-configuration.patch which is not directly applicable to MacPorts since that requires a ./prepare script to be run first (and ./prepare script only exist in Gnuplot's CVS repository). Is anyone here willing to play with gnuplot's trunk version (or 4.6.0 outside of macports) and help me test the patch? The major problem is that patch per-se works for me, but when I run "./prepare", I get zillions of updated Makefile.in etc. If I try to "backport" just the relevant changes, I end up with g++ & c++ complaining about 'Bool' and clang++ working fine on exactly the same sources. If I run ./prepare myself and don't try to backport anything (but then I end up with a huge patch), it seems to work fine.

Any volunteer?

I would say that it would indeed make sense to first upgrade to 4.6.0 and to figure out the right patch for Qt later.

[trg818 (Thomas Ruedas)]

Cc Me!

[mojca (Mojca Miklavec)]

Patch for update to Gnuplot 4.6.0 with support for Qt and both wxWidgets/wxWidgets-devel

[mojca (Mojca Miklavec)]

I would like to ask for some testing of gnuplot4_6_0.diff added above. It updates to gnuplot 4.6.0 and adds two variants: qt & wxwidgets_devel (on top of wxwidgets itself). I updated one patch that has been used before, added two upstream bugfixes for xwt & qt, and one long & ugly patch that should enable building qt terminal on mac.

I only tested on 64-bit Lion so far.

[mojca (Mojca Miklavec)]

While looking at other options & history more carefully (in particular cairo's path:lib/pkgconfig/pango.pc:pango) I realized that it would also make sense to replace

    depends_lib-append      port:qt4-mac

with something that qt4-mac-devel would satisfy (but not qt3 or qt3-mac). This is less important than other patches, but I would be grateful for suggestions. I could come up with something like

    depends_lib-append      path:lib/pkgconfig/QtCore.pc:qt4-mac

but this is probably not good enough to exclude qt3 and might not work if framework option leaves those pc files out.

[mojca (Mojca Miklavec)]

I just tested on Snow Leopard and then discovered that kProcessTransformToBackgroundApplication is listed on Lion Api diff list at ​http://developer.apple.com/library/mac/#releasenotes/General/MacOSXLionAPIDiffs/ApplicationServices.html.

typedef UInt32 ProcessApplicationTransformState;
enum {
  kProcessTransformToForegroundApplication = 1,
  kProcessTransformToBackgroundApplication = 2, /* functional in Mac OS X Barolo and later */
  kProcessTransformToUIElementApplication = 4 /* functional in Mac OS X Barolo and later */
};

It seems that gnuplot with qt would need an additional patch to work on 10.6 and earlier.

[michaelld (Michael Dickens)]

To be able to depend on either qt4-mac and qt4-mac-devel, use the PortGroup for Qt4: "PortGroup qt4 1.0". It takes care of all that, and sets up the build environment for QMake, CMake, and others. See, e.g., py-pyqt4 Portfile.

[mojca (Mojca Miklavec)]

Like the following?

variant qt description "Enable Qt terminal" {
    PortGroup qt4 1.0
    configure.args-append   --enable-qt
}

All perfect, the code compiles fine, except that gnuplot doesn't end up in /opt/local/bin/gnuplot as it should (despite being a "Qt application", it should still start as a command-line application) and I suspect that PortGrup qt4 is the culprit in that case, simply trying to do "too much favour" to the user.

[michaelld (Michael Dickens)]

I would bet that the executable is being made into a .app by QMake, and then placed into /Applications/MacPorts (using default values) or /Applications/MacPorts/Qt4 . Do a "port destroot gnuplot" and then go into the destroot directory and find what you're looking for. I'll put myself on CC so you don't have to email me directly.

[michaelld (Michael Dickens)]

Cc Me!

[mojca (Mojca Miklavec)]

QMake won't work with gnuplot (gnuplot doesn't have any Qt-specific configuration, it uses just autoconf, configure, make, make install) and I don't have anything under /Applications/MacPorts/Qt4 (plenty of other applications, but nothing related to gnuplot).

</path/to/destroot>/opt/local/bin/gnuplot binary ends up under destroot as it probably should, but it doesn't get transferred to /opt/local/bin/gnuplot during installation for some reason.

(PS: tests were done by replacing "depends_lib-append port:qt4-mac" with "PortGroup qt4 1.0" in ​gnuplot4_6_0-v2.diff)

Apart from that the patch itself seems to work fine for me under 10.6-10.8 (under 10.6 I also tried with +universal, but I didn't test with wxwidgets 2.8, I only went through different combinations of wxwidgets_devel and qt switched on and off). It would help if it would work with qt4-mac-devel as well, but that is lower on the priority list and from my point of view - if it cannot be resolved quickly, it is fully acceptable if it only works with qt4-mac. In particular because this would be the first time to have support for Qt at all.

The patch for Qt needs to end up upstream in gnuplot one day. So for those who know a bit more about the topic I would also be grateful for feedback about which approach has more sense: using Cocoa (needs a separate file since Cocoa header cannot be read inside C++ file) or Carbon? Either of them is only needed for a single function call at the moment; one that hides one useless gnuplot instance from Dock.

[mojca (Mojca Miklavec)]

Replying to ryandesign@…:

I tested on Snow Leopard with Xcode 3.2.6. With default variants + universal it built fine. With default variants + universal + qt it failed with "qtterminal/qt_term.cpp:314: error: ‘kProcessTransformToBackgroundApplication’ was not declared in this scope". wxWidgets-devel is building now; will test gnuplot +qt later.

Can you please try again with either ​gnuplot4_6_0-v2.diff or ​gnuplot4_6_0-v2-cocoa.diff? The two patches should give the same result (unless I screwed up somewhere), it is only a matter of preference which one is used.

The only remaining issue I'm aware of is that qt4-mac-devel could be accepted as a dependency in addition to qt4-mac, but this has way lower priority.

[mojca (Mojca Miklavec)]

Unrelated, but for anyone following or reading this ticket: what would be the most suitable option name to make x11, qt or wxwidgets the default terminal instead of aquaterm?

I would really like to change the default terminal (for me, not for everyone) once in future. I know how to write the code to do that, but I don't know how to call the options. Something like the following?

port install gnuplot +qt +wxwidgets +default_qt
port install gnuplot +qt +default_x11

The options would then be (default_aqua), default_qt, default_wxt (or default_wxwidgets), default_x11, all conflicting with each other. (But all that is a bit ugly.)

[mojca (Mojca Miklavec)]

Thomas Ruedas wrote:

Ugly or not, I think it makes sense the way you suggest, and I can't think of something better. I also prefer the x11 terminal, so I would definitely use such an option. I am following the ticket but can for some reason not post to the list

[mojca (Mojca Miklavec)]

In the light of planned changes to upgrade qt4-mac to Qt 4.8 in a couple of days there is no reason to care about "PortGroup qt4" any more. A simple dependency on qt4-mac will do.

[michaelld (Michael Dickens)]

Ports that require qt4-mac should in general use the qt4 portgroup unless there is some good reason to not do so. It provides and will continue to provide "shortcuts" to install locations (e.g., plugins) and other directories, and includes qt4-mac and/or -devel correctly. So, my recommendation is to keep using it when possible. Maybe there are some ports where it is not efficient to do so, but I don't remember any off the top of my head.

[mojca (Mojca Miklavec)]

I would be perfectly happy to use PortGroup qt4, but unless somebody can figure out why installation doesn't end up with a binary in /opt/local/bin/gnuplot, an explicit dependence on qt4-mac seems to be the only option for now. I don't know enough about internals of macports to be able to "debug".

[michaelld (Michael Dickens)]

Not reading the above carefully yet, I assume from what you write that when you include the qt4 portgroup then gnuplot is not installed into $[prefix]/bin, but when you just include qt4-mac directly then gnuplot is installed correctly? Seems like a configure issue, most likely. I'll have time to look at this in the next couple of weeks, if it's still an issue then.

[mojca (Mojca Miklavec)]

Replying to michaelld@…:

I assume from what you write that when you include the qt4 portgroup then gnuplot is not installed into $[prefix]/bin, but when you just include qt4-mac directly then gnuplot is installed correctly?

Yes, exactly.

[mojca (Mojca Miklavec)]

One of the patches from this ticket (detecting bool in "./configure" script) also solves the problems mentioned in #31483.

[mojca (Mojca Miklavec)]

Same as gnuplot4_6_0-v2.diff (but using Cocoa instead of Carbon).

[mojca (Mojca Miklavec)]

Last version of the patch to upgrade gnuplot to 4.6.0 (almost the same as gnuplot4_6_0-v2-cocoa.diff)

[mojca (Mojca Miklavec)]

The latest update also addresses ticket #18795.

[mkae (Marko Käning)]

At least patch gnuplot4_6_0-v2.diff needs a "-p1" argument for patch. Would be easier if patches submitted would not need the "-p" argument, since in that case the use of the trac-patch macro works out of the box by simply copying the patch's URL into the terminal like this:

$ trac-patch http://trac.macports.org/attachment/ticket/33596/gnuplot4_6_0-v2.diff

[mkae (Marko Käning)]

I just installed the 4.6.0 using your patch.

Unfortunately no output window appears when I call gnuplot and simply say e.g. "plot sin(x)".

Yet, there is output when I switch to x11 with "set term x11".

:-(

[mkae (Marko Käning)]

I did no install a variant, but just used "sudo port install gnuplot". So, no qt4-mac etc. involved here.

Didn't try your cocoa patch though...

[mkae (Marko Käning)]

Cc Me!

[mojca (Mojca Miklavec)]

Replying to mk@…:

I just installed the 4.6.0 using your patch.

Unfortunately no output window appears when I call gnuplot and simply say e.g. "plot sin(x)".

I guess that you have the same issue with current gnuplot? This is most probably a problem with AquaTerm and updating gnuplot alone won't help.

1.) Which OS version do you use? Is it 64-bit (I guess it is)? 2.) What does "port installed aquaterm" and "port installed gnuplot" return you? In particular I'm interested if gnuplot is running in 32-bit mode. 3.) When AquaTerm is not running, can you please try "open -a AquaTerm" and check for "Open Files and Ports" to see which AquaTerm opens by default (and what is its bitness)?

Making sure that you don't run gnuplot in 32-mode and that you don't have a different version of AquaTerm.app on the system should help. But I will try to provide a patch for AquaTerm to solve this problem. I'm fully aware that AquaTerm 1.0.1 has issues.

PS: What makes most sense to test in 4.6.0 would be "wxt" and "qt". (Printing in qt is broken, but I don't know how to solve that yet.)

[mkae (Marko Käning)]

Ooops, it was my own mistake as it turns out now.

When I start aquaterm manually and then run gnuplot with "plot sin(x)" the output gets displayed just fine.

I expected that gnuplot would open up aquaterm on its own, which it obviously did not...

I am running Snow Leopard:

$ port installed gnuplot aquaterm
The following ports are currently installed:
  aquaterm @1.0.1_5 (active)
  gnuplot @4.4.4_0+luaterm+pangocairo
  gnuplot @4.6.0_0+luaterm+pangocairo (active)

which is 64 bit, I'd guess.

[pixilla (Bradley Giesbrecht)]

See r92569