#572 better handling of AquaTerm detection and configuration


The basic idea is the following. The system first calls GP_APPLE which only sets $is_apple to yes or no. Later on (you may move the checks to any other place you want), if system is Mac OS X, it checks if user disabled AquaTerm. If yes, it proceeds without AquaTerm, else it checks if user provided any special flag to tell against which AquaTerm gnuplot should be linked and adds one "LDFLAG" (LIBS=-F/path/to/Frameworks). So if AquaTerm is not disabled, it checks whether AquaTerm works. In case it does, it includes it.

An Apple user may:
- ./configure --without-aquaterm which will disable AquaTerm
- ./configure --with-aquaterm[=yes] which will keep AquaTerm (default setting anyway)
- ./configure --with-aquaterm=/path/to/Frameworks which will add
-F/path/to/Frameworks to $LIBS

In the last case, it might be that user still needs to add -I/path/to/include. I don't know any good way around that problem (given that Per is reluctant to support pkg-config) apart from explicitly specifying CFLAGS=-I/path/to/includes. On the other hand:
- includes should most probably be equivalent or at least compatible
- I have no idea how to influence which file will be included if multiple files are present; but if they are compatible, it is selection of library the one that matters most; the header file is not so important

The patch is composed of two parts:
- AC_CHECK_FRAMEWORK (borrowed from other OpenSource project - the same code is in several projects; maybe it should be renamed into AX to follow guidelines of local additions to autotools macros)
- the code in configure.in that I wrote myself and does what is described above.

What are problems of current (old) approach / why is the patch needed?
- Per (author of AquaTerm) would like to get rid of libaquaterm.dylib and only keep the framework (that is "the Mac way"). This patch is needed to let him do that.
- Current configuration checks whether -laquaterm works from system-wide installation, but if at least some other library is included, it will use AquaTerm.framework from MacPorts (not the one that was being checked for) and then again call system-wide AquaTerm.app. In case of incompatibilities this might cause problems. I can explain more if needed. The patch doesn't solve 100 % of possible problems with incompatibilities, but it greatly improves the situation.
- Patch adds flexibility to use a different AquaTerm framework in case that there are multiple frameworks installed.
- Patch adds ability to disable AquaTerm terminal. That didn't make any sense in past, but now that Qt, wxt and X11 all work satisfactory, there might be people who don't want to have AquaTerm as the default terminal (lack of mouse events) or don't want to have it built at all. Currently the only option to avoid building with AquaTerm support is to remove AquaTerm from the system.


  • Mojca Miklavec

    Mojca Miklavec - 2012-04-25

    I uploaded a new patch. The part with problems with CFLAGS=-I/path/to/includes is no longer true.

    In current implementation there is no need to have any extra include path - simply the one from framework itself is being used. Configuration can also easily be tested by trying out "mojca" branch of https://github.com/mojca/gnuplot

  • Mojca Miklavec

    Mojca Miklavec - 2012-04-25

    I'm sorry, I forgot to add some framework flags to CFLAGS as well. (I did an extensive testing of previous patch and slighly less extensive one on this one.) I'll upload a new version as soon as I make sure that I didn't skip anything else.

  • Mojca Miklavec

    Mojca Miklavec - 2012-04-25

    The last attached patch looks fine after some additional testing using --with-aquaterm=/opt/local/Library/Frameworks (and removing AQTAdapter.h from include path).

  • Aljaž Srebrnič

    The patch looks good and is already applied in the MacPorts version of gnuplot. It works reliably.

  • Ethan Merritt

    Ethan Merritt - 2013-09-24
    • status: open --> closed-out-of-date
    • Group: -->

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks