Please see
https://github.com/johnkerl/miller/releases where there are builds for OSX
Yosemite, Linux i686 (statically linked), and Linux x86-64 (dynamically
linked).
Homebrew installation support for OSX is available via
POKI_CARDIFY(brew update && brew install miller)HERE
You may already have mlr available in your platform’s
package manager on NetBSD, Debian Linux, Ubuntu Xenial and upward, Arch Linux, or perhaps other distributions.
For example, on Debian/Ubuntu, you can try
POKI_CARDIFY(sudo apt-get install miller)HERE
Building from source
From release tarball using autoconfig
Miller allows you the option of using GNU autoconfigure to build portably.
Grateful acknowledgement: Miller’s GNU autoconfig work was done by
the generous and expert efforts of Thomas
Klausner.
Obtain mlr-i.j.k.tar.gz from https://github.com/johnkerl/miller/tags,
replacing i.j.k with the desired release, e.g. 2.2.1.
tar zxvf mlr-i.j.k.tar.gzcd mlr-i.j.k
Install the following packages using your system’s package manager
(apt-get, yum install, etc.):
automake autoconf libtool flex (if you need to run autoreconf -fiv) else just
libtool flex
Various configuration options of your choice, e.g.
autoreconf -fiv (no longer necessary as of 5.2.0)
./configure./configure --prefix=/usr/local./configure --prefix=$HOME/pkgs./configure CC=clang./configure --disable-shared (to make a statically linked executable)
./configure 'CFLAGS=-Wall -std=gnu99 -O3'
etc.
make creates the c/mlr executable
make checkmake install copies the c/mlr executable to your prefix’s bin subdirectory.
From git clone using autoconfig
git clone https://github.com/johnkerl/millercd miller
Then continue from “Install the following ... ” as above.
Without using autoconfig
GNU autoconfig is familiar to many users, and indeed plenty of folks won’t bother to use an open-source
software package which doesn’t have autoconfig support. And this is for good reason: GNU autoconfig allows
us to build software on a wide diversity of platforms. For this reason I’m happy that Miller supports
autoconfig.
But, many others (myself included!) find autoconfig confusing: if it works
without errors, great, but if not, the ./configure && make
output can be exceedingly difficult to decipher. And this also can be a
turn-off for using open-source software: if you can’t figure out the
build errors, you may just keep walking. For this reason I’m happy that
Miller allows you to build without autoconfig. (Of course, if you have any
build errors, feel free to contact me at
kerl.john.r+miller@gmail.com,
— or, better, open an issue with “New Issue” at
https://github.com/johnkerl/miller/issues.)
Steps:
Obtain a release tarball or git clone.
cd into the c subdirectory.
Edit the INSTALLDIR in Makefile.no-autoconfig.
To change the C compiler, edit the CC= lines in
Makefile.no-autoconfig and dsls/Makefile.no-autoconfig.
make -f Makefile.no-autoconfig creates the mlr
executable and runs unit/regression tests (i.e. the equivalent of both
make and make check using autoconfig).
make install copies the mlr executable to your install directory.
The Makefile.no-autoconfig is simple: little more than gcc
*.c. Customzing is less automatic than autoconfig, but more transparent.
I expect this makefile to work with few modifications on a large fraction of
modern Linux/BSD-like systems: I’m aware of successful use with
gcc and clang, on Ubuntu 12.04 LTS, SELinux, Darwin (MacOS
Yosemite), and FreeBSD.
Windows (beta)
Status as of 2017-04-15: Miller is built on Windows using MSYS2: http://www.msys2.org/. You can install MSYS2
and build Miller from its source code within MSYS2, and then you can use the
binary from outside MSYS2. You can also use a precompiled binary.
Precompiled binaries
Miller releases from 5.1.0w
onward will have a precompiled Windows binary, in addition to the MacOSX, Linux
32-bit static, and Linux 64-bit precompiled binaries as on previous releases.
Important caveat: due to the issue tracked in
https://github.com/Alexpux/MSYS2-packages/issues/872, you will need to
download three files: the mlr.exe file as well as
libpcre-1.dll and libpcreposix-0.dll. This situation is
unfortunate and inconvenient; I felt it worthwhile to get a Windows beta out to
users (due to demand) while this issue is being resolved.
For example:
C:\> mkdir \mbin.
Then place
libpcreposix-0.dll,
libpcre-1.dll, and
mlr.exe all into C:\mbin. Then put that into your %PATH%, e.g. with
C:\> set PATH=%PATH%;\mbin.
Building from source
You will first need to install MSYS2: http://www.msys2.org/.
Then, start an MSYS2 shell, e.g. (supposing you installed MSYS2 to
C:\msys2\) run C:\msys2\mingw64.exe. Within the MSYS2 shell,
you can run the following to install dependent packages:
There are (at present) two manual edits, not yet (as of 2017-04-15)
automated into the configuration process. One is to edit
c/lib/mlr_arch.h and add #define MLR_ON_MSYS2 on its own line
right above #ifdef MLR_ON_MSYS2. The other is to edit
c/Makefile.am and c/unit_test/Makefile.am and add a space and
-lpcreposix after -lm.
Then (still within the MSYS2 shell) proceed as above with
autoreconf.fiv, ./configure, and make. There is a
unit-test false-negative issue involving the semantics of the mkstemp
library routine but a make -k in the c subdirectory has been
producing a mlr.exe for me.
Within MSYS2 you can run mlr: simply copy it from the c
subdirectory to your desired location somewhere within your MSYS2
$PATH. To run mlr outside of MSYS2, just as with precompiled
binaries as described above, you’ll need the two DLLs. One way to do
this is to augment your path:
C:\> set PATH=%PATH%;\msys64\mingw64\bin
Another way to do it is to copy the Miller executable and the two DLLs all to the same directory:
These are necessary to produce the mlr
executable.
gcc, clang, etc. (or presumably other compilers; please
open an issue or send me a pull request if you have information for me about
other 21st-century compilers)
The standard C library
flexautomake, autoconf, and libtool, if you build with autoconfig
Optional external dependencies
This documentation pageset is built using Poki:
docs here,
source code here.
Note that http://johnkerl.org/miller/doc/index.html
is nothing more than Miller’s doc directory served up by a web server.
You’ll need poki if you modify documents, or if you modify the code in a way that affects the documents
(there are auto-run snippets inserted into the doc).
The best way to discover this is to run make install as above, then run poki in Miller’s
doc subdirectory, then run git diff to see if docs were affected
by the code mod. (If so, commit and push them.)
Internal dependencies
These are included within the Miller source tree and do not
need to be separately installed (and in fact any separate installation will not be picked up in the Miller build):
At present I’m the primary developer so this is just my checklist for making new releases.
In this example I am using version 3.4.0; of course that will change for subsequent revisions.
Update version found in mlr --version and man mlr:
Edit configure.ac, c/mlrvers.h, and mlr.spec
from 3.3.2-dev to 3.4.0.
make -C c -f Makefile.no-autoconfig installhome &&
make -C doc -f Makefile.no-autoconfig all installhome
Commit and push.
ISP upload so http://johnkerl.org/miller/doc/index.html
will have updated head-docs.
Create the release tarball and SRPM:
On buildbox: ./configure && make distcheck
On buildbox: make SRPM as in
https://github.com/johnkerl/miller/blob/master/README-RPM.md
On all buildboxes: cd c and make -f Makefile.no-autoconfig mlr.static. Then copy
mlr.static to ../mlr.{arch}.
Pull back release tarball mlr-3.4.0.tar.gz and SRPM mlr-3.4.0-1.el6.src.rpm from buildbox,
and mlr.{arch} binaries from whatever buildboxes.
Create the Github release tag:
Write the release notes
Attach the release tarball, SRPM, and binaries
Publish the release
Create the release-specific docs:
Pull the Github-generated source .tgz from Github to ISP
miller-releases directory and unpack and cd into it.
cd into doc subdir. Edit template.html’s titleinbody tag from
Miller to Miller 3.4.0 and poki-build.
ISP upload
At the ISP site, update the latest-revision symlink
ln -s pub_http_internet/miller-releases/miller-3.4.0 pub_http_internet/miller.
(This is the main doc URL linked to from the top of the Github repo so it
must point to this newly published revision.)
Back in the Github repo, edit doc/content-for-release-docs.html to include new release, poki-build,
push/commit, and ISP upload.
Notify:
Submit brew pull request; notify any other distros which don’t appear to have autoupdated
since the previous release.