More Mac cloning thoughts

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

More Mac cloning thoughts

Thomas Mattison-2
This is on a Mac mini Core 2 Duo running 10.6.8.

So far, my recipe is

Install Aquaterm application and XQuartz

Do .configure, make, sudo make install, and make DESTDIR=/tmp/gnuplot on the following:
zlib-1.2.8, libpng-1.5.26, freetype-2.4.10, gd-2.0.33, gnuplot-5.0.3

This produces a gnuplot with the built-in terminals, X11, Aquaterm, png, and gif.
That's enough to be useful.

It also produces a tree under /tmp/gnuplot which has  /usr/local/, under which is
/bin/ containing the gnuplot executable, and lots of other executables made by the libraries above
/libexec/ containing /gnuplot/5.0/gnuplot_x11
/lib/ containing the libraries made above
/include/ containing headers for the above libraries
/share/man/man1 with gnuplot.1 and gnuplot-ja.a
/share/man3/ and /share/man5/ with library man files
/texlive/ with a tree leading to gnuplot.cfg

A simple sudo rsync on a different Mac should push all that stuff into the standard locations as if it had been built there.
For the target case of a student Mac not used for Unix development, would that be expected to cause problems?

If it would cause problems, is there some simple way to configure the build process so the gnuplot executable would look in some non-standard directory for the libraries, so I could make the rsync put the libraries where they wouldn't cause trouble on the target system?



I realize that if the target Mac is used for Unix-style development, doing the rsync would be ill-advised.
But if the Mac is used for Unix-style development, then it would be easy to just do a local build of gnuplot,
and the rsync approach wouldn't be needed.




Hopefully Allin Cottrell's gnuplot.app for Mac will become a regular product.  Then non-developer Mac users will be able to enjoy Gnuplot, like non-developer Windows users.  And my humble efforts at cloning Mac installations will be irrelevant.  





                                      Cheers

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



------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|

Re: More Mac cloning thoughts

tmacchant
----- Original Message -----

> From: Thomas Mattison
> To: gnuplot-beta
> Cc:
> Date: 2016/3/6, Sun 04:32
> Subject: More Mac cloning thoughts
>
>T his is on a Mac mini Core 2 Duo running 10.6.8.
>
> So far, my recipe is
>
> Install Aquaterm application and XQuartz
>
> Do .configure, make, sudo make install, and make DESTDIR=/tmp/gnuplot on the
> following:
> zlib-1.2.8, libpng-1.5.26, freetype-2.4.10, gd-2.0.33, gnuplot-5.0.3
>
> This produces a gnuplot with the built-in terminals, X11, Aquaterm, png, and
> gif.
> That's enough to be useful.
>
> It also produces a tree under /tmp/gnuplot which has  /usr/local/, under which
> is
> /bin/ containing the gnuplot executable, and lots of other executables made by
> the libraries above
> /libexec/ containing /gnuplot/5.0/gnuplot_x11
> /lib/ containing the libraries made above
> /include/ containing headers for the above libraries
> /share/man/man1 with gnuplot.1 and gnuplot-ja.a
> /share/man3/ and /share/man5/ with library man files
> /texlive/ with a tree leading to gnuplot.cfg
>
> A simple sudo rsync on a different Mac should push all that stuff into the
> standard locations as if it had been built there.
> For the target case of a student Mac not used for Unix development, would that
> be expected to cause problems?
>
> If it would cause problems, is there some simple way to configure the build
> process so the gnuplot executable would look in some non-standard directory for
> the libraries, so I could make the rsync put the libraries where they
> wouldn't cause trouble on the target system?
>
>
>
> I realize that if the target Mac is used for Unix-style development, doing the
> rsync would be ill-advised.
> But if the Mac is used for Unix-style development, then it would be easy to just
> do a local build of gnuplot,
> and the rsync approach wouldn't be needed.
>
>
>
>
> Hopefully Allin Cottrell's gnuplot.app for Mac will become a regular
> product.  Then non-developer Mac users will be able to enjoy Gnuplot, like
> non-developer Windows users.  And my humble efforts at cloning Mac installations
> will be irrelevant. 
>

I am one of volunteers who makes windows binary for regular release (e.g. 5.0.0 etcs.)
I also have uploaded cvs snapshot of windows and Cygwin binaries.

I have never used modern Mac. I sometime uses Linux (Ubuntu 14.04).

On windows, build process of gnuplot does not use configure but uses specific makefile.
For mingw build, specific makefile is very powerful.
One can build full featured gnuplot, GUI help file, all documents including manual,
windows installer and zip archived packages using the specific makefile if
one can prepare all libraries and external tools.

For Unix like environments, I do not think that package management system should be
included in configure and makefile system of gnuplot.
My opinion is that out of box managements should be desirable.

> Do .configure, make, sudo make install, and make DESTDIR=/tmp/gnuplot on the
> following:
> zlib-1.2.8, libpng-1.5.26, freetype-2.4.10, gd-2.0.33, gnuplot-5.0.3

I recommend to link with also the fontconfig library. Without it,
the gd based terminals (png, gif,(jpeg)) cannot pull full features of gnuplot.
(Font specification like "set terminal png font 'Helvatica, 12'"
and Bold and Italic in the enhanced text mode.)

And gd-2.0.33 is out of date.
If possible, please use gd library version of which is 2.1.0 or higher.
(gd-2.0.33 has a bug for fontconfig treatments.)

> It also produces a tree under /tmp/gnuplot which has  /usr/local/, under which
> is
> /bin/ containing the gnuplot executable, and lots of other executables made by
> the libraries above
> /libexec/ containing /gnuplot/5.0/gnuplot_x11
> /lib/ containing the libraries made above
> /include/ containing headers for the above libraries
> /share/man/man1 with gnuplot.1 and gnuplot-ja.a
> /share/man3/ and /share/man5/ with library man files
> /texlive/ with a tree leading to gnuplot.cfg

Terminals that are built without external libraries include
the postscript and the canvas terminal and they require additional
files.

On cygwin (cvs 5.1.0) binaries that I distribute is considered to install
to /opt/gp510
Under /opt/gp510

bin: gnuplot.exe (exe extention windows specific) and shared library for wxwidgets
that are not supported in the official Cygwin.

libexec/gnuplot/5.1/: gnuplot_x11.exe

share/gnuplot/5.1/ : additional script and gnuplot.gih (help file)

share/gnuplot/5.1/Postscipt : files required to use postscript terminal and documents.

share/gnuplot/5.1/app-defaults : "Gnuplot"  the file should be placed at appropriate
place that depends on environmets if you use x11 terminal.

share/gnuplot/5.1/js : files and documents for the canvas terminal.

share/gnuplot/5.1/lua files and documents for lua/tikz terminal.
(In your configuration, lua directory is not necessary.)

Include directory is not necessary but lib directory may not be omitted
if it includes shared libraries (.so files).

Hope the above helps.

Tatsuro

------------------------------------------------------------------------------
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta