Opened 10 years ago
Closed 10 years ago
#43738 closed update (fixed)
gnuplot: upgrade to 5.0
Reported by: | mojca (Mojca Miklavec) | Owned by: | mojca (Mojca Miklavec) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | haspatch | Cc: | mkae (Marko Käning), cooljeanius (Eric Gallager), Schamschula (Marius Schamschula), maehne (Torsten Maehne), lrmlalo@… |
Port: | gnuplot |
Description
Gnuplot 5.0-RC1 is out, however there are a bunch of slight incompatibilities compared with version 4.6.
I would like to request some testing before the official release.
Attachments (3)
Change History (35)
comment:3 Changed 10 years ago by mkae (Marko Käning)
Hi Mojca, I just got it built fine on 10.9.2, but during destroy ended up with this:
---> Staging gnuplot into destroot Error: org.macports.destroot for port gnuplot returned: xinstall: Cannot stat: /opt/local/var/macports/distfiles/gnuplot/5.0.rc1/gnuplot.pdf, No such file or directory
comment:4 Changed 10 years ago by mojca (Mojca Miklavec)
Thanks for noticing, just a stupid mistake:
-
Portfile
old new 163 163 164 164 set destdocdir ${destroot}${prefix}/share/doc/${name} 165 165 xinstall -d -m 0755 ${destdocdir} 166 xinstall -m 0644 ${ distpath}/${name}.pdf ${destdocdir}166 xinstall -m 0644 ${workpath}/${distname}/docs/${name}.pdf ${destdocdir} 167 167 168 168 # copy demo files 169 169 file copy ${workpath}/${distname}/demo ${destdocdir}
Changed 10 years ago by mojca (Mojca Miklavec)
Attachment: | gnuplot-5.0-RC1.Portfile added |
---|
Gnuplot 5.0-RC1
comment:5 Changed 10 years ago by mkae (Marko Käning)
OK, now it installs fine. I didn't do any real tests.
comment:6 follow-up: 9 Changed 10 years ago by dbevans (David B. Evans)
A few lint problems
$ port lint --nitpick ---> Verifying Portfile for gnuplot Error: Line 8 repeats inclusion of PortGroup xcodeversion Warning: Line 87 has trailing whitespace before newline Warning: Dependency path:lib/pkgconfig/pango.pc:pango specified multiple times in depends_lib ---> 1 errors and 2 warnings found.
comment:7 follow-up: 10 Changed 10 years ago by dbevans (David B. Evans)
Dependency issue:
gnuplot will optionally build with libcerf support if that port is installed. Probably should add this as a dependency or explicitly disable this feature (don't see an obvious configure option to do this though).
comment:8 follow-up: 12 Changed 10 years ago by mkae (Marko Käning)
My goodness, how did you spot this?
comment:9 Changed 10 years ago by mojca (Mojca Miklavec)
Replying to devans@…:
Error: Line 8 repeats inclusion of PortGroup xcodeversion
That's a bug in MacPorts, not in the port. MacPorts have problems with uppercase letters in the PortGroup
name.
Warning: Line 87 has trailing whitespace before newline
OK, trivial, I'll fix this
Warning: Dependency path:lib/pkgconfig/pango.pc:pango specified multiple times in depends_lib
Would the following patch be OK? (But that's also the case in current port.)
-
Portfile
108 108 109 109 variant wxwidgets description "Enable wxt terminal" { 110 110 wxWidgets.use wxWidgets-3.0 111 depends_lib-append port:${wxWidgets.port} path:lib/pkgconfig/pango.pc:pango 111 depends_lib-append port:${wxWidgets.port} 112 if {![variant_isset pangocairo]} { 113 depends_lib-append path:lib/pkgconfig/pango.pc:pango 114 } 112 115 configure.args-delete --disable-wxwidgets 113 116 configure.args-append --with-wx=${wxWidgets.wxdir} 114 117 }
comment:10 follow-up: 13 Changed 10 years ago by mojca (Mojca Miklavec)
Replying to devans@…:
Dependency issue:
gnuplot will optionally build with libcerf support if that port is installed. Probably should add this as a dependency or explicitly disable this feature (don't see an obvious configure option to do this though).
Weird. Because I was the creating a port for libcerf and I was complaining to gnuplot developers that they need to add better support for searching for libcerf to configure.in
. And I forgot to add dependency. The dependency is totally optional (I don't know what it's used for), it's small (the compressed binary package is 54K) and has no further dependencies on its own. So maybe I should just include it unconditionally.
Changed 10 years ago by pixilla (Bradley Giesbrecht)
Attachment: | patch-gnuplot-pango.diff added |
---|
comment:11 Changed 10 years ago by pixilla (Bradley Giesbrecht)
I was not aware of #!diff :)
How about this:
-
math/gnuplot/Portfile
100 100 } 101 101 102 102 variant pangocairo description "Enable cairo-based terminals" { 103 depends_lib-append path:lib/pkgconfig/pango.pc:pango104 103 configure.args-delete --without-cairo 105 104 } 106 105 … … 111 110 112 111 variant wxwidgets description "Enable wxt terminal" { 113 112 wxWidgets.use wxWidgets-3.0 114 depends_lib-append port:${wxWidgets.port} path:lib/pkgconfig/pango.pc:pango113 depends_lib-append port:${wxWidgets.port} 115 114 configure.args-delete --disable-wxwidgets 116 115 configure.args-append --with-wx-config=${wxWidgets.wxdir} 117 116 } … … 138 137 default_variants-append +wxwidgets 139 138 } 140 139 140 if {[variant_isset pangocairo] || [variant_isset wxwidgets]} { 141 depends_lib-append path:lib/pkgconfig/pango.pc:pango 142 } 141 143 # Building and installing TeX macro files for TikZ could/should be done by gnuplot's Makefile, 142 144 # but without a patch that would require a dependency on texlive. 143 145 # Apart from that the files would fly to the wrong place in TDS,
comment:12 Changed 10 years ago by dbevans (David B. Evans)
Replying to mk@…:
My goodness, how did you spot this?
Since we have been using the buildbots, I usually try testing ports as follows
sudo port deactivate active sudo port configure gnuplot
This emulates the way the buildbots work and helps spot missing dependencies. Doing this yielded a configure message regarding no libcerf and then I looked to see if it was available in MacPorts.
Note that I do this on a separate testing machine not a production one as this can be time consuming if you have a lot of ports installed. But it does help spot build failures due to missing dependencies before submission to the buildbots.
comment:13 Changed 10 years ago by dbevans (David B. Evans)
Replying to mojca@…:
Replying to devans@…:
Dependency issue:
gnuplot will optionally build with libcerf support if that port is installed. Probably should add this as a dependency or explicitly disable this feature (don't see an obvious configure option to do this though).
Weird. Because I was the creating a port for libcerf and I was complaining to gnuplot developers that they need to add better support for searching for libcerf to
configure.in
. And I forgot to add dependency. The dependency is totally optional (I don't know what it's used for), it's small (the compressed binary package is 54K) and has no further dependencies on its own. So maybe I should just include it unconditionally.
Yes, I'd just add the dependency. My understanding is that it adds additional scripting commands based on the functionality of libcerf. One of the included demos, cerf.dem, illustrates this usage.
comment:14 Changed 10 years ago by mojca (Mojca Miklavec)
comment:15 follow-up: 16 Changed 10 years ago by dbevans (David B. Evans)
The port has a very extensive and well anotated set of demos which not only serve as a test of functionality but also a nice tutorial. After building the port, I was able to run them all successfullly but only after I overcame a few of my own naive assumptions.
First try. The all-inclusive demo, all.dem is installed in ${prefix}/share/doc/gnuplot/demo so I did this
cd ~ gnuplot ${prefix}/share/doc/gnuplot/demo/all.dem
This fails with file not found errors because the file references in the scripts are interpreted as relative to the CWD.
Second try
cd ${prefix}/share/doc/gnuplot/demo gnuplot all.dem
This works better but fails again if the script issues any warning/error messages. gnuplot is trying to write these messages to a log file which by defalt is located in the CWD but the user usually doesn't have write permission to the MacPorts installation tree.
Third try, copy the demos to a writable directory in the user's home directory
mkdir ~/macports/gnuplot cp -R ${prefix}/share/doc/gnuplot/demo ~/macports/gnuplot cd ~/macports/gnuplot/demo gnuplot all.dem
Success!! All demos work correctly.
I acknowlege again that this was all due to my naive ideas about how a demo might work but you might consider adding some notes to the Portfile advertizing the demos as a starting point for the naive user and how to install them locally so they work without hiccups. This would answer the question, "Ok, I installed the port -- what now?"
comment:16 follow-up: 17 Changed 10 years ago by mojca (Mojca Miklavec)
Replying to devans@…:
This would answer the question, "Ok, I installed the port -- what now?"
I fully sympathize with that, but ... isn't this a problem with almost any given package (other than those with a nice gui)?
comment:17 follow-up: 20 Changed 10 years ago by dbevans (David B. Evans)
Replying to mojca@…:
Replying to devans@…:
This would answer the question, "Ok, I installed the port -- what now?"
I fully sympathize with that, but ... isn't this a problem with almost any given package (other than those with a nice gui)?
Yes, but this is a particularly complex package and the demos are an easy way to come up to speed. However, there is nothing that immediately tells you that there are demos or how to run them. But I guess you could leave it up to the user to figure it out (as I did) and wait for the tickets to come in saying the demos are broken. :-) I'll leave it up to you.
comment:18 Changed 10 years ago by dbevans (David B. Evans)
One more minor suggestion concerning the +qt variant. I note that the package supports both qt4 and qt5 so perhaps the current variant should be +qt4 anticipating the porting of qt5 some time in the future when you could add +qt5.
Other than what I've posted previously, it looks like everything is working. I did some more testing this afternoon and was able to output to aquaterm, a wxt term window and an x11 term window with no problems using the default variants. However, when I build with +qt in addition to the default variants and try to use a wxt term for output I get the following:
gnuplot> set term wxt Terminal type set to 'wxt' The wxt terminal cannot be used in a qt session
Using
set term qt
works fine, so it may be that the +qt and +wxWidgets-3.0 variants should be made mutually exclusive.
Overall, a nice data visualization package.
comment:19 Changed 10 years ago by mojca (Mojca Miklavec)
I just wanted to say that Qt5 needs testing ;) We spent o lot of time debugging it, but I'm not sure if the work was ever finished (I did not dive into programming, I was just a tester), but of course there is no way to do it inside macports unless you are willing to compile it yourself with external Qt5.
But indeed some extra testing for Qt4 (including printing which was broken in 4.x, at least to some point) would be helpful.
To answer your question: qt
and wxt
are not mutually exclusive. The problem is that (they claim that) one cannot switch between qt
and wxt
. If you have aquaterm
installed, you can always switch to either of them. But once you switch to qt
(and do something with it), you cannot switch to wxt
any longer. Not sure if qt
as default terminal prevents you from using wxt
altogether.
The suggestion about qt4
makes sense. I'm just not sure whether it's better to introduce it now or when qt5
starts being supported in MacPorts.
comment:20 Changed 10 years ago by mojca (Mojca Miklavec)
Replying to devans@…:
Yes, but this is a particularly complex package and the demos are an easy way to come up to speed. However, there is nothing that immediately tells you that there are demos or how to run them. But I guess you could leave it up to the user to figure it out (as I did) and wait for the tickets to come in saying the demos are broken. :-) I'll leave it up to you.
What exactly would you write in the notes?
I remember my first experience from windows. One runs the exe, uses File->Open and it opens at location where the program is installed, so one just needs to pick the folder demo
and then all.dem
(or any other file for that matter). But I don't know how to replicate that user experience on Mac lacking a standalone Gnuplot.app (which would require a tiny bit of Qt expertise to write a Qt gui with "built-in" "terminal" to resemble the behaviour in windows).
comment:22 Changed 10 years ago by mojca (Mojca Miklavec)
I added support for Qt5 in r121585. I suspect there's something wrong either with Gnuplot's configuration or with Qt5 installation, else I wouldn't need those extra flags.
comment:23 Changed 10 years ago by mojca (Mojca Miklavec)
I committed RC3 to my personal folder in r128087.
Do we need gnuplot-devel
perhaps? Here's a notice sent to the gnuplot mailing list (for me the nicest thing is "save to file" from wxt):
There is a source tarball on SourceForge for the 3rd (final) version 5.0 release candidate. I do not expect much to change between -rc3 and the final 5.0 release, but if your valuable testing uncovers a problem there is still time to fix it. The user-visible changes since -rc2 are ============================= - revised "fit" command + syntax: fit {<ranges>} <expression> '<datafile>' {datafile-modifiers} {{unitweights} | {y|xy|z}error | errors <var1>{,<var2>,...}} via '<parameter file>' | <var1>{,<var2>,...} + this is a CHANGE from -rc1 and -rc2 + most version 4 "fit" syntax is detected and emulated even though the command options have changed. Also there is now an explicit command "set fit {v4|v5}" to force ambiguous commands to be interpreted as they were in version 4. - completion of time/date format changes begun in -rc1 and -rc2 + formats used for input and output are now distinct + fime format used to read input data or range/position commands is specified by 'set timefmt' or timecolumn(column,"timeformat') + timecolumn(column) uses default from 'set timefmt' as in version 4 + time format used to output axis tic labels is specified by set {xyz}tics {timedate|geographic|numeric} format "..." + new format modifier "t" distinguishes a time interval from a date - wxt terminal has an Export-to-File widget on the toolbar - various bug fixes (see NEWS and ChangeLog) Known issues (no resolution expected before 5.0) ==================================== - the wxt terminal emits runtime warnings and errors if gnuplot is built using wxWidgets 3.0 rather than 2.8
Changed 10 years ago by mojca (Mojca Miklavec)
Attachment: | gnuplot-5.0.diff added |
---|
Upgrade to version 5.0 and make a gnuplot-4.6 subport
comment:24 Changed 10 years ago by mojca (Mojca Miklavec)
I attached a diff with an upgrade to version 5.0. A subport for version 4.6.6 is also included. Please test and provide feedback.
comment:25 Changed 10 years ago by mojca (Mojca Miklavec)
I'm also thinking about inclusion of the following patch to show help in HTML format rather than just in text mode:
It seems very useful. I got it working with wxt and I still need to debug what's wrong with qt, but it looks nice.
comment:28 follow-up: 31 Changed 10 years ago by mojca (Mojca Miklavec)
Yes, I attached a patch to upgrade to 5.0 a few days ago and I'm waiting for some feedback.
On the other hand I'm thinking about trying to simply upgrade to 5.0 and wait if anyone will have any problems at all. If no users have problems switching to 5.0, maybe there's no need to bother about support for 4.6.
comment:31 Changed 10 years ago by lrmlalo@…
Replying to mojca@…:
Yes, I attached a patch to upgrade to 5.0 a few days ago and I'm waiting for some feedback.
On the other hand I'm thinking about trying to simply upgrade to 5.0 and wait if anyone will have any problems at all. If no users have problems switching to 5.0, maybe there's no need to bother about support for 4.6.
Is there an estimated time of release for version 5? I think 5.0.0 offers some very useful new possibilities I'd need; but I was to silly to use your provided patchfile
comment:32 Changed 10 years ago by mojca (Mojca Miklavec)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Only if anyone starts complaining about the differences, I might reconsider adding back support for 4.6.