gnuplot 5.0.0 +aquaterm fails to include support for aquaterm

[michaelld (Michael Dickens)]

The configure patch from 4.6.6 was not ported to 5.0.0, so gnuplot now fails to find the Aquaterm header, but does not fail building; it just does not support the "aqua" terminal even with the +aquaterm set. At least for me running 10.8, Xcode 5.1.1 (but, I think this will be generic since it's a compiler arguments issue rather than OS related).

configure:8866: checking for Aquaterm framework presence
configure:8887: /usr/bin/clang -o conftest -pipe -Os -arch x86_64 -I/opt/local/include -I/opt/local/include   -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -F/opt/local/Library/Frameworks -arch x86_64 -L/opt/local/lib -lcerf  -framework Foundation -framework Aquaterm conftest.m  >&5
conftest.m:32:9: fatal error: 'Aquaterm/AQTAdapter.h' file not found
#import <Aquaterm/AQTAdapter.h>

I think the "right" solution is to recreate the configure patch; an alternative that might work is to set some *FLAGS in the configure.env.

[michaelld (Michael Dickens)]

"port configure gnuplot" log

[michaelld (Michael Dickens)]

"config.log

[mojca (Mojca Miklavec)]

Replying to michaelld@…:

The configure patch from 4.6.6 was not ported to 5.0.0, so gnuplot now fails to find the Aquaterm header, but does not fail building; it just does not support the "aqua" terminal even with the +aquaterm set.

It's not that I didn't port it. But I'm unable to reproduce the failure.

At least for me running 10.8, Xcode 5.1.1 (but, I think this will be generic since it's a compiler arguments issue rather than OS related).

configure:8866: checking for Aquaterm framework presence
configure:8887: /usr/bin/clang -o conftest -pipe -Os -arch x86_64 -I/opt/local/include -I/opt/local/include   -I/opt/local/include -L/opt/local/lib -Wl,-headerpad_max_install_names -F/opt/local/Library/Frameworks -arch x86_64 -L/opt/local/lib -lcerf  -framework Foundation -framework Aquaterm conftest.m  >&5
conftest.m:32:9: fatal error: 'Aquaterm/AQTAdapter.h' file not found
#import <Aquaterm/AQTAdapter.h>

I think the "right" solution is to recreate the configure patch;

I tried to convince the upstream to support --with-aquaterm=PATH, but they didn't understand my patch and they thought it was too complicated. Eventually they started supporting --with[out]-aquaterm in some very limited way. Maybe someone should ask the autotools developers to introduce a macro to search for frameworks on Mac.

I could reintroduce the previous patch in MacPorts, but I first need to understand why this approach doesn't work for you.

an alternative that might work is to set some *FLAGS in the configure.env.

I did.

configure.cflags-append     "-F${frameworks_dir}"
configure.ldflags-append    "-F${frameworks_dir}"

What I don't understand is why your compiler doesn't find the framework despite -F/opt/local/Library/Frameworks. After all my patch for configure didn't do anything else but add that flag, except maybe to a different location.

[michaelld (Michael Dickens)]

Some sleuthing: I run a case-sensitive file system. "Aquaterm" framework is installed as "AquaTerm", not "Aquaterm". gnuplot looks for the latter, which is not found because of the "t" (actual is "T"). Should be a simple patch to the configure script.

[mojca (Mojca Miklavec)]

Ah, that explains it. I didn't notice that tiny detail.

But there's another issue then. Is problematic just the part with -framework AquaTerm? What about

#import <aquaterm/AQTAdapter.h>

in term/aquaterm.trm and

#import <Aquaterm/AQTAdapter.h>

in configure script?

So we need to two two things now:

• create a patch for MacPorts (patching the configure script)
• submit the patch upstream (patching the sources for configure script)

Can you please test the attached patches?

[mojca (Mojca Miklavec)]

A patch for configure sources for case sensitive file systems (for upstream)

[mojca (Mojca Miklavec)]

A patch for configure script for gnuplot for case sensitive systems

[mojca (Mojca Miklavec)]

A patch for aquaterm.trm for gnuplot for case sensitive systems (most probably optional)

[michaelld (Michael Dickens)]

Yes, those patches work; with them, AquaTerm is found and support is built for it cleanly; octave works out of the box with the updated gnuplot without having to be rebuild. Nice!

I think reporting this issue upstream is important, too; thanks for putting together that patch as well.

I'm attaching the "svn diff" that includes the renamed patches & augmented Portfile. Feel free to use this diff or make your own.

[mojca (Mojca Miklavec)]

But once again (just for my curiosity): is the (minimum) necessary modification just -framework AquaTerm or is it also necessary to use the right capitalisation in #include/#import?

[michaelld (Michael Dickens)]

If I do "sudo port patch gnuplot", then go in and modify the configure script to look for "#import <aquaterm/AQTAdapter.h>" (but, I don't change the framework name; it is still AquaTerm as patched), then run "sudo port configure gnuplot", then AquaTerm support is not found. Hence, the first part of the #import (or #include) string must match the framework name; and for case-sensitive file systems this means matching the case as well.

[mojca (Mojca Miklavec)]

In that case you need to explain me something. How is it possible that AquaTerm worked for you in 4.6.6 that contains

#ifdef TERM_BODY
#import <aquaterm/AQTAdapter.h>
...

in aquaterm.trm?

[michaelld (Michael Dickens)]

The patch fixes this to be "AquaTerm/AQTAdapter.h"; it also fixes the configure script to look for this header instead of "Aquaterm/" ...

[mojca (Mojca Miklavec)]

I'm sorry. I forgot that the fix for aquaterm.trm was also part of my patch for 4.6.6. That explains why it didn't fail for 4.6.6. All is clear then. Both patches are absolutely needed.

Here's the upstream bug report: ​https://sourceforge.net/p/gnuplot/bugs/1571/

The commit in r133274 should restore some of the missing functionality that has been removed in r133179. (I'm not following the general guides for naming the patch files – as long as we only require a single patch that's related to a single upstream problem that should be OK.)

[michaelld (Michael Dickens)]

OK; good to get your issues worked out; your changes work for me. Thanks for your prompt attention & working through this with me!

[mojca (Mojca Miklavec)]

This has already been fixed upstream, so 5.0.1 should hopefully work out of the box again.

[michaelld (Michael Dickens)]

Great; nice work pushing it upstream & the quick acceptance of it!

[mojca (Mojca Miklavec)]

Now you should try to compile branch-5-0 from upstream to verify that I/they didn't miss something ;)

[michaelld (Michael Dickens)]

Meh. I've got plenty of other more important things to do :)