Feature request: make clone

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

Feature request: make clone

Thomas Mattison-2
Hi

Would it be possible to add a target to the makefile that will create a directory containing copies of everything that "make install" delivers, plus a short script that will do with the contents of that directory what "make install" does?

The idea is that "make clone" would create a directory that could be copied to a different computer.  Then running the script in the directory on that computer would put the gnuplot components where they need to be, without the need to compile them.

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.

The instructor might want other items in the clone-directory and the clone-script, like libgd, libpng, freetype, and zlib, but that could be done manually after "make clone" has done its thing.


                                      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



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
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: Feature request: make clone

Allin Cottrell
On Wed, 2 Mar 2016, Thomas Mattison wrote:

> Would it be possible to add a target to the makefile that will
> create a directory containing copies of everything that "make
> install" delivers, plus a short script that will do with the
> contents of that directory what "make install" does?

If I'm understanding the request correctly, not only would it be
possible, but it's already possible. You do, for example,

make DESTDIR=/tmp/gnuplot install

and under /tmp/gnuplot you find the entire tree that "make install"
creates. You can probably see where to take things from there, in
terms of packaging the result.

Allin Cottrell

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
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: Feature request: make clone

Mojca Miklavec
In reply to this post by Thomas Mattison-2
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.

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.

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
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: Feature request: make clone

Thomas Mattison-2
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
[hidden email]         phone: 604-822-9690  fax:604-822-5324



------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
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: Feature request: make clone

sfeam

On Wednesday, 02 March, 2016 14:22:28 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

>

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

 

Core Duo is a 32-bit chip and can only run 32-bit executables.

Core 2 Duo is a 64-bit chip and you could use it to build and run

either a 32-bit or a 64-bit executable.

Clearly if your intent is to carry the resulting executable over

to a 32-bit machine, you need to build a 32-bit executable.

 

Ethan

 

 

 

>

> 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

> [hidden email] phone: 604-822-9690 fax:604-822-5324

>

>

>

> ------------------------------------------------------------------------------

> Site24x7 APM Insight: Get Deep Visibility into Application Performance

> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month

> Monitor end-to-end web transactions and take corrective actions now

> Troubleshoot faster and improve end-user experience. Signup Now!

> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140

> _______________________________________________

> gnuplot-beta mailing list

> [hidden email]

> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
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: Feature request: make clone

Mojca Miklavec
In reply to this post by Thomas Mattison-2
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

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
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: Feature request: make clone

Plotter-2
In reply to this post by Allin Cottrell
On 02/03/16 20:26, Allin Cottrell wrote:
> On Wed, 2 Mar 2016, Thomas Mattison wrote:
>
>> >Would it be possible to add a target to the makefile that will
>> >create a directory containing copies of everything that "make
>> >install" delivers, plus a short script that will do with the
>> >contents of that directory what "make install" does?


What you are trying to do is called cross-compiling ( compiling fora
target  platform that is different to that on which the compiling is
being done ).

The configure scripts supplied with gnuplot will moan very loudly if
they do not find the appropriate dependencies on the machine ( unless
you do lots of stuff to circumvent the checks and this will likely give
a big mess to deal with later ).

Unless your target students are geeky types I would say just stick to
pre-built gnuplot packages on their respective systems.

building and maintaining out of tree , non distribution packages is not
rocket science but it's not kindergarten logo-land either. It will just
create problems unless they know enough to keep on top of it.

Peter.


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
gnuplot-beta mailing list
[hidden email]
Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta