Re: Feature request: make clone

[Mojca M. <moj...@gm...>]

On 2 March 2016 at 23:22, Thomas Mattison wrote:
> 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

Again ... if possible, try to install everything but the final binary
to a different prefix to avoid weird conflicts later on.

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

Oh, sorry, yes, you need a matching architecture as well. But there
are only two choices: i386, x86_64 (as well ass ppc and ppc64 with
some subvariants to be complete, but I hope you are not targeting
those).

Core 2 Duo will give you 64-bit binaries by default (I think) or
32-bit on request. Core Duo won't work with 64-bit at all.

The times of 32-bit processors are so far away that I completely
forgot about that problem (even if I'm currently thinking of buying a
PowerMac).

If you would want to target both in a single go, you could build with
"-arch i386 -arch x86_64", but that has to be done for all
dependencies as well and you'll end up with double size of the
binaries, so it's probably better to provide two separate variants
anyway. Or you could give 32-bit binaries to everyone. This should
work, but I wouldn't advise you to do that. (I would be a bit
surprised if your students still used 32-bit notebooks though. Apple
switched to 64-bit in 2006.)

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

All they have to do is fetch Xcode via App store. In case of HomeBrew
it might be sufficient to install just command line tools. Yes, they
need to do something, but it's not a rocket science and it is
certainly trivial compared to trying to build gnuplot by themselves.

But they get a big added value: they end up with a fully functional
package manager that they will be able to use for almost anything
else. If you teach them gnuplot, they might be interested to try
Octave next for example. Or who knows what.

> It's just hard for non-computer-science students to
> get their Macs configured to the point that they can do the build process.

Figuring out how to compile gnuplot was super hard for me as well (and
I needed a few years before I figured it out). I wouldn't advice
teaching students how to compile gnuplot, that would be way too
complicated for absolutely no added value.

But installing Xcode is just as easy as installing anything else.

> (Linux boxes have all the compiler and package manager and X-windows stuff by default).

No, not all of them do. I've seen some boxes without a compiler.
(Sure, all you need is to install the compiler with a trivial command
or with a sequence of mouse clicks.)

But if you show the students how easy it is to install the compiler
and a package manager, they might be grateful later on. If you give
them some files with soon-to-be-outdated gnuplot binaries, they'll
lose the binaries as soon as they upgrade the OS and will have no idea
where to get new ones.

Mojca