Menu
▾
▴
gnuplot-beta
|
From: Per P. <per...@ma...> - 2004-10-21 12:00:27
|
Hi, I've cleaned up my distro script for Mac OS X and would like to add it and it's supporting files to CVS. I suppose the top dir rather than src/ is the appropriate location for a directory with the files? Any objections to naming that dir "MacOSXDistro"? It relies on a GPL'd utility to pack stuff up. AINAL, but that should not AFAICT cause any license violations. Comments? (I'm changing jobs next week so I'd like to get this out of the way before then.) /Per |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-21 16:08:23
|
On Thursday 21 October 2004 05:00 am, Per Persson wrote: > Hi, > I've cleaned up my distro script for Mac OS X and would like to add it > and it's supporting files to CVS. > > I suppose the top dir rather than src/ is the appropriate location for > a directory with the files? > Any objections to naming that dir "MacOSXDistro"? I'm not objecting, at least not yet, but I'm curious exactly what files these are. I managed to install gnuplot on OSX directly from the existing tree, and I am a total novice user to OSX. What is needed beyond what is there already? > It relies on a GPL'd utility to pack stuff up. AINAL, but that should > not AFAICT cause any license violations. Comments? The existing build chain uses many GPL utitilities (gmake, autoconf, etc). -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Per P. <per...@ma...> - 2004-10-21 17:08:20
|
On Oct 21, 2004, at 18:08, Ethan Merritt wrote: > On Thursday 21 October 2004 05:00 am, Per Persson wrote: >> Hi, >> I've cleaned up my distro script for Mac OS X and would like to add it >> and it's supporting files to CVS. >> >> I suppose the top dir rather than src/ is the appropriate location for >> a directory with the files? >> Any objections to naming that dir "MacOSXDistro"? > > I'm not objecting, at least not yet, but I'm curious exactly what files > these are. I managed to install gnuplot on OSX directly from the > existing > tree, and I am a total novice user to OSX. What is needed beyond > what is there already? I'm talking about a script and supporting files to create the binary installer and documentation in PDF that people right now are downloading from SF. Nobody is questioning your ability to type ./configure;make but some users prefer a double-clickable standard installer. In case I choose not to devote time to this project anymore, at least there would be a way to create an installer for Mac OS X from a point release by running a script. This was previously discussed: On Oct 2, 2004, at 13:15, Hans-Bernhard Broeker wrote: > >> In the long term, should I add the script (that creates installers) >> and >> a few (3 at the moment) supporting files to gnuplot or should I keep >> it >> separate? > > I think they should go into gnuplot. We already lost at least one > complete Macintosh port because its source never was integrated with > the mainline source. No good reason to let that happen again. Well, It might happen again. >> It relies on a GPL'd utility to pack stuff up. AINAL, but that should >> not AFAICT cause any license violations. Comments? > > The existing build chain uses many GPL utitilities (gmake, autoconf, > etc). This was in response to a question raise by HBB in a previous mail. /Per |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-21 17:16:38
|
On Thursday 21 October 2004 10:08 am, Per Persson wrote: > > Nobody is questioning your ability to type ./configure;make but some > users prefer a double-clickable standard installer. > In case I choose not to devote time to this project anymore, > at least there would be a way to create an installer for Mac OS X > from a point release by running a script. How stable is this standard installer? If no one maintains the OSX-specific files in your new directory, will we risk losing the benefit of your work because the installer files themselves no longer function under Tiger or its successor? I'm not objecting to including it, but I'd like a better feel of how much benefit it is to future work. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-10-21 17:27:51
|
Ethan Merritt wrote: >On Thursday 21 October 2004 10:08 am, Per Persson wrote: > > >>Nobody is questioning your ability to type ./configure;make but some >>users prefer a double-clickable standard installer. >>In case I choose not to devote time to this project anymore, >>at least there would be a way to create an installer for Mac OS X >>from a point release by running a script. >> >> > >How stable is this standard installer? > This is what I was going to ask. My faith in GUI installers isn't strong. But I hear plenty of good things about OS X, so... Dan |
|
From: Per P. <per...@ma...> - 2004-10-21 21:05:49
|
On Oct 21, 2004, at 19:16, Ethan Merritt wrote: > > How stable is this standard installer? Very. Apple delivers OS X with it. I probably should have been more precise previously * The installer (executable) is part of the OS * The installer package (as the one I'm creating for gnuplot) is just a particular file hierarchy (referred to as a bundle) that appears as a single item to the user. It contains the files to install, any scripts that need to be run during the install process and a description of where to put stuff etc. * The "distro script" I wrote simply[1] build and install gnuplot into a temporary destination, creates the PDF documentation files etc. It then uses a third party utility to create an installer package (i.e. not an executable). The reasons to choose a tool other than the one supplied by Apple are several, all good and valid. Finally, it wraps everything up as a "disk image", a compressed format suitable for distribution. * In addition to the files neccessary to create the install package, I also added a ReadMe file and a copy of the license. [1] It actually makes a small change to allow gnuplot to be built on 10.3 and deployed on earlier systems (stpcpy wasn't standard prior to 10.3) > > If no one maintains the OSX-specific files in your new directory, > will we risk losing the benefit of your work because the installer > files themselves no longer function under Tiger or its successor? Only if Apple decides to break every installer in existance. The only problems I can see with future releases of OS X would apply to _any_ form of binary distribution, where you build on Y and deploy on Z. > > I'm not objecting to including it, but I'd like a better feel of > how much benefit it is to future work. Hopefully, a lot. /Per |
