POKI_PUT_TOC_HERE

Miller license

Two-clause BSD license https://github.com/johnkerl/miller/blob/master/LICENSE.txt.

Prebuilt executables

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.

From git clone using autoconfig

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:

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:

pacman -Syu
pacman -Su
pacman -S base-devel
pacman -S msys2-devel
pacman -S mingw-w64-x86_64-toolchain
pacman -S mingw-w64-x86_64-pcre
pacman -S msys2-runtime

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:

C:\> mkdir \mbin
C:\> copy \msys64\mingw64\bin\libpcreposix-0.dll \mbin
C:\> copy \msys64\mingw64\bin\libpcre-1.dll \mbin
C:\> copy \msys64\wherever\you\installed\miller\c\mlr.exe \mbin
C:\> set PATH=%PATH%;\mbin

The Windows port is still beta: please open an issue at https://github.com/johnkerl/miller/issues if you encounter any problems.

Continuous build using Appveyor

Currently Miller is autorun using Travis on every build (https://travis-ci.org/johnkerl/miller/builds). This was set up by the generous assistance of SikhNerd on Github, tracked in https://github.com/johnkerl/miller/issues/15. There is a similar continuous-build system for Windows. As of 2017-04-15 https://ci.appveyor.com/project/johnkerl/miller is not correctly set up, but in the future, it will auto-build Miller commits and releases.

In case of problems

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.

Dependencies

Required external dependencies

These are necessary to produce the mlr executable.

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):

Creating a new release: for developers

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.

Misc. development notes

I use terminal width 120 and tabwidth 4.