gnuplot on MacOS X (2nd attempt at #1166)

[kowey]

#1166 removed the emacs dependency and built with the aqua driver by default on Mac. But there are two problems:

1. we need emacs for the Gnuplot Lisp code
2. this aqua driver thing seems to require that AquaTerm be installed on compile time

So this version sticks with the X11 version by default, but offers a top-level gnuplot_aquaterm that you can use to build a more Mac-y gnuplot.

I haven't yet dared contribute an Aquaterm derivation because I don't really know what I'm doing. It's currently installed as a “framework” (/Library/Frameworks/AquaTerm.framework) which I dimly understand to be self-contained collections of libraries. I imagine some future nixpkgs will be able to install frameworks too so you get something like ~/.nix-profile/Frameworks.

[peti]

I have some doubts about the change from emacs to emacs-nox. Wouldn't it be much better to customize the default emacs attribute so that it doesn't pull in gtk when building on Darwin?

What bothers me about emacs-nox is that this attribute is used nowhere else, really, and I ended up building another copy of Emacs just to build gnuplot despite the fact that I have a full-blown Emacs in my store already. I realize it's a build-time only dependency and it's going to be gargabe-collected and all, but it still feels a little awkward.

Anyway ... I don't feel strongly about this. Just my 2 cents.

[vcunat]

IMO it would be theoretically best if the core (needed for compiling stuff) could be factored out and shared (perhaps just by splitting the resulting binaries into multiple outputs). A quick search shows that e.g. Ubuntu does it, so it's possible to take inspiration how to do the build if it's more complicated.

[peti]

Yes, that's true. That would be even nicer.

[kowey]

Hmm, I could go either way. I was under the impression that the non-gtk Emacs on Darwin route was not preferred and so went with emacs-nox instead. But am happy to revise this again to go that route. Should I make a new pull request?

[peti]

@kowey, yes, please open a new pull request. It's probably a good idea to split the emacs change off your other patch and to submit two separate pull requests for those two so that they don't block each other.

[kowey]

Replaced by attempt #1197