On Mon, 21 Sep 2015, Clive Nicholas wrote: Thank you Clive, this is absolutely terrific, thanks a lot for putting this together, I's sure it'll be very helpful for lots of Linux users out there (and thanks for your kind words on the package) I have a list of small tweaks you may want to consider, but as I said your video is already very good as is now, so feel free to decide if you want to upload an updated version or not. * at least on my laptop, the audio was a bit crackling; perhaps you'll want to speak a little farther away from the mike * instead of copying-and-pasting the long URL from sourceforge, you can just "wget http://prdownloads.sourceforge.net/gretl/gretl-1.10.2.tar.xz";; wget should "get" the redirection and work straight away * a very desirable consequence of building your home-baked version of gretl is that you'll have it optimised for your machine. On modern PCs, for example, you may take advantage of multiple CPUS and have a few operations (such as matrix products or random-effects probit, for example) run faster. In order to enable this, you'll have to add the --enable-openmp option to ./configure * also, if you add the --enable-build-doc option and run "make pdfdocs" after "make", you'll also have updated versions of the pdf files, which can be handy * again, parallel is good; you can cut down build time dramatically by giving the "-j" option to make, as in, for example "make -j2", or "make -j4" * some users may worry about all those warnings during build; in most cases, they're totally harmless * a quicker way to perform a version check: just do "cli/gretlcli -v" instead of "gui2/gretl_x11", so you use the CLI client instead, which is much quicker * to get the CVS version, the way the video shows is the best one, but if you're feeling impatient you may also navigate to "http://gretl.cvs.sourceforge.net/viewvc/gretl/gretl/" and download the tarball. However, keep in mind that we'll probably be switching from CVS to git soon. * to see what's new, you may either go to "Help>About>News", or open http://gretl.sourceforge.net/ChangeLog.html. * it may be nice to remind that we have an active community who's willing to help and say something about the mailing lists. Thanks again for your nice work! ------------------------------------------------------- Riccardo (Jack) Lucchetti Dipartimento di Scienze Economiche e Sociali (DiSES) Università Politecnica delle Marche (formerly known as Università di Ancona) r.lucchetti(a)univpm.it http://www2.econ.univpm.it/servizi/hpp/lucchetti -------------------------------------------------------

*Jack,Oops! As I say, in response:* * at least on my laptop, the audio was a bit crackling; perhaps you'll want to speak a little farther away from the mike *The audio could have been considerably de-burred, I must admit. The sound cut-outs weren't great, either. I use an internal mike from one port and I'm still experimenting with Vokoscreen, so I shall do some more tinkering when making future videos.* * instead of copying-and-pasting the long URL from sourceforge, you can just "wget http://prdownloads.sourceforge.net/gretl/gretl-1.10.2.tar.xz";; wget should "get" the redirection and work straight away * a very desirable consequence of building your home-baked version of gretl is that you'll have it optimised for your machine. On modern PCs, for example, you may take advantage of multiple CPUS and have a few operations (such as matrix products or random-effects probit, for example) run faster. In order to enable this, you'll have to add the --enable-openmp option to ./configure * also, if you add the --enable-build-doc option and run "make pdfdocs" after "make", you'll also have updated versions of the pdf files, which can be handy *All three of these are excellent tips which I'd no idea of (no doubt, you'll tell me I should have RTFM more closely). Thanks!* * again, parallel is good; you can cut down build time dramatically by giving the "-j" option to make, as in, for example "make -j2", or "make -j4" *Which -make -j*- option would you recommend?* * some users may worry about all those warnings during build; in most cases, they're totally harmless * a quicker way to perform a version check: just do "cli/gretlcli -v" instead of "gui2/gretl_x11", so you use the CLI client instead, which is much quicker * to get the CVS version, the way the video shows is the best one, but if you're feeling impatient you may also navigate to " http://gretl.cvs.sourceforge.net/viewvc/gretl/gretl/" and download the tarball. However, keep in mind that we'll probably be switching from CVS to git soon. *Again, thanks for these excellent tips. Will you please tell us Linux users know exactly how we should get Git updates from our terminals when you announce it?** to see what's new, you may either go to "Help>About>News", or open http://gretl.sourceforge.net/ChangeLog.html. *Like an idiot, I realised straight away I should have said this on review of the video.* * it may be nice to remind that we have an active community who's willing to help and say something about the mailing lists. *Agreed.* Thanks again for your nice work! *No problem, you're welcome. Now here's a tip for you: why not incorporate all of these steps into the next version of the User Guide? That way, all newcomers have a clear point-by-point 'guide within a guide' to work with. :)* *Yours,* *Clive Nicholas*

Am 22.09.2015 um 00:20 schrieb Riccardo (Jack) Lucchetti: I might be missing something, but isn't Appendix C exactly such a step-by-step guide? -sven

It would be nice if there was complete description of what is needed to build Gretl quartz on OS X. Inspecting the package contents and doing some "otool -L …" magic building gretl-quartz seems to be quite involved. Berend

I would describe how to build the complete App bundle and make the package for distribution; both the Quartz version and the X11 version. I assume you are building the whole thing in a do-it-yourself way and using clang (and gfortran? if yes which one?). It’s just nice to have an account for the “just in case” scenario. I have never used/use MacPorts or Homebrew. I always seem to read about problems and issues and they are not “Mac-ish”. So I keep away from these. I don’t know if anyone is using Macports or Homebrew. Everything needed is then in the bundle and if I or someone else needs the command line version of gretl or gnuplot making a script to access those two wouldn’t be too difficult. I’m certainly going to try making two scripts for accessing gretlcli and gnuplot from a Terminal. I would be able to get rid of your GTK+ framework and the Aquaterm.framework. I appreciate your hard work in building a Quartz version of Gretl and a WXT terminal for gnuplot. The Quartz version is much nicer than an X-windows version. I don’t use them daily; only once in a while. Very nice to have (both of them). Berend

On Tue, 22 Sep 2015, Berend Hasselman wrote: You're probably right, best to avoid MacPorts and Homebrew. As you assume, I'm following the do-it-yourself approach (and using what's supplied with OS X itself as far as possible). Thanks, Berend. Here's a first stab at an outline (more to follow). For now, I can offer a quick overview of a build process for Gretl.app. (I should be able to follow up with actual scripts, but it'll take a while to convert these from my cross-versions to native, and to test them on a Mac.) The overall strategy is: (1) create suitable trees in which (a) to build things and (b) to install things; (2) build a few required tools if they're not already on your system; (3) build and install the needed third-party libraries; (4) build and install gretl. In a bit more detail: (1) Start by creating a directory tree to hold the app bundle, as in sudo mkdir -p /Applications/Gretl.app/Contents/Resources sudo mkdir /Applications/Gretl.app/Contents/MacOS You could choose some location other than /Applications as the target, but in that case all binaries, dylibs and .so modules will probably have to be retargeted using install_name_tool. (Although that's not a big deal with a clever shell script.) Also create a tree under your $HOME for storing sources and building stuff. Just for example: mkdir -p ~/gretl-build/sources (2) Tools: you'll need (besides the Xcode command-line tools) a downloader (curl would do, though I prefer wget), an extractor for xz files such as unxz, pkg-config, and GNU gettext. At this point a strategic decision is required: do you want to build something closely resembling the Gretl.app that we distribute, or would you like to build an "all-in-one" kit which you could pass on to other people, hence enabling them to build gretl from source? In the former case you'd install the tools outside of Gretl.app (probably in /usr/local or somewhere under /opt); in the latter case, you could install them into the bundle filespace. But note that gettext is a special case: it comprises both build tools and a library, libintl.dylib, that's needed inside the app bundle. If you install gettext outside of the app (as I do) you then have to copy libintl into the bundle and "fix it up" with install_name_tool. (3) Dependencies, not provided by OS X: these include GMP, MPFR, fftw3, libpng, readline, the complete GLib/GTK stack with pango and cairo, gtksourceview and gtkmacintegration. You build these and install them into the app bundle tree. That means that when running their configure scripts you specify as --prefix /Applications/Gretl.app/Contents/Resources or wherever else you chose at step (1). (Alternatively, you can install them elsewhere, then copy everything that's actually needed into the app bundle tree, but that's a good deal more fiddly.) Note that a fair number of the gretl's dependencies are, fortunately, supplied by OS X, for example zlib, libxml2, libiconv and libcurl. Everything you, as builder, need for these libraries should be provided by the appropriate Xcode SDK, and everything the end-user needs should be provided by the OS itself. (4) If all has gone well to this point, it should be possible to configure the gretl sources to install into Gretl.app, build and install. There's no need for a fortran compiler unless you want to in addition to build X12A (or X13AS nowadays) or TRAMO/SEATS. As I said, I'll try to follow up with actual scripts (with configuration details) plus specification of package versions and a few patches for certain third-party libraries. Allin