#572 better handling of AquaTerm detection and configuration

None
closed-out-of-date
nobody
None
5
2013-09-24
2012-01-19
Mojca Miklavec
No

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.

Discussion

  • 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

    Patch for AquaTerm detection

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

     
  • 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: -->