Re: Feature request: make clone

[Thomas M. <mat...@ph...>]

Thanks Allin and Mojca for the quick answers!

make DESTDIR=/tmp/gnuplot    did exactly what you said: made a small tree of stuff.

I wrote a simple script:

#!/bin/sh
sudo cp -r usr/local/bin/*     /usr/local/bin
sudo cp -r usr/local/libexec/* /usr/local/libexec
sudo cp -r usr/local/share/*   /usr/local/share
sudo cp -r usr/local/texlive/* /usr/local/texlive

I did the build on a Mac running 10.6.8, put the tree and the script on a flash drive, moved it to another Mac running 10.6.8, and ran the script.  It seems to have put things where I wanted, but when I tried running there, I got the error

bash: /usr/local/bin/gnuplot: Bad CPU type in executable

The build was done on a 2.4 GHz Intel Core 2 Duo machine, the destination was a 2 GHz Intel Core Duo.
They are different CPU types.  So apparently more needs to match than just the OS version.

In any case, I've gotten as close to what I want as is reasonably, and unreasonably quickly!




On 2016-03-02, at 1:43 PM, Mojca Miklavec wrote:

> On 2 March 2016 at 20:49, Thomas Mattison wrote:
>> 
>> The motivation for this is mostly for installing gnuplot on Mac's of non-computer-science students.  Only one person (like an instructor) would need to download the compiler, download the gnuplot source, build the executables, and create the clone-directory.  Everyone else would just copy the clone-directory and run the script inside.
>> 
>> I realize this would not necessarily work if the student Mac is running a different system version from the instructor.  It may be necessary to make a different clone-directory for each OS X system version.  But it would only be necessary to do ONCE per version, and not require EVERY student to install the compiler and do the build.
>> 
>> I also realize that students would still need to install Aquaterm and/or X11, but those have "real" installers so it's not such a big deal.
> 
> Allin already answered in the same way as I would.
> 
> I wanted to add that you usually only have to build a binary for the
> oldest OS and that should automatically work on newer OS versions.
> 
> But what about using a package manager like MacPorts or Homebrew? You
> would then get all the dependencies (including AquaTerm, X11, Qt, wxt,
> pango, cairo, gd, ...) as well a all the updates automatically.


I thought that Macports etc still required students to install the compilers,
which is what I'm trying to avoid.


> 
> In any case I would advise you to try to install the headers and
> libraries somewhere else than in /usr/local to avoid "messing up" the
> system.
> 
> Mojca
> 
> PS: If someone would write a similar Qt- or wxt-based GUI as the one
> for Windows (that is: an app that starts with a GUI rather than in a
> terminal), I would volunteer to create a binary for OS X. The main
> annoyance is packaging a binary for the terminal.


I would be overjoyed with a Mac binary that just ran inside the default
Terminal.app or an xterm window, with no extra GUI at all!  The functionality
is fine as-is.  It's just hard for non-computer-science students to
get their Macs configured to the point that they can do the build process.
(Linux boxes have all the compiler and package manager and X-windows stuff by default).




                                      Cheers

Prof. Thomas Mattison           Hennings 276
University of British Columbia  Dept. of Physics and Astronomy
6224 Agricultural Road          Vancouver  BC        V6T 1Z1  CANADA
mat...@ph...         phone: 604-822-9690  fax:604-822-5324