GaloisInc/cryptol
1
1
Fork 0
mirror of https://github.com/GaloisInc/cryptol.git synced 2024-12-15 18:52:13 +03:00
Code Issues Projects Releases Wiki Activity
5c80fc2e1c
cryptol/Makefile

271 lines
8.8 KiB
Makefile
Raw Normal View History

distribution tweaks Makefile now has two modes depending on whether PREFIX is set. If it's not, we try to make the distribution as relocatable as possible, meaning we don't rely on the baked-in-by-cabal data directory. If it is set, we do use that path.
2015-03-04 03:22:14 +03:00
HERE := $(realpath $(dir $(lastword $(MAKEFILE_LIST))))
update notebook build mechanisms
2015-02-06 03:12:36 +03:00
Initial import from internal repo
2014-04-18 02:34:25 +04:00
UNAME := $(shell uname -s)
ARCH := $(shell uname -m)
Adds more support for UTF-8 in identifiers Also: - Improves the `lexical error` message, changing it to `unrecognized character`, and only displaying the one character that caused the problem. - Adds more relevant text when showing a lexical error, which should address #219 - Switches parser to operate over lazy `Data.Text` rather than `String`
2015-05-27 00:21:54 +03:00
TESTS ?= parser issues regression renamer mono-binds
Make the diff command line absolute
2014-12-05 01:36:26 +03:00
TEST_DIFF ?= meld
Initial import from internal repo
2014-04-18 02:34:25 +04:00
Allow expected failures to be ignored
2015-03-31 02:58:33 +03:00
IGNORE_EXPECTED ?= --ignore-expected
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
CABAL_BUILD_FLAGS ?= -j
CABAL_INSTALL_FLAGS ?= $(CABAL_BUILD_FLAGS)
Initial import from internal repo
2014-04-18 02:34:25 +04:00
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
CABAL := cabal
CABAL_BUILD := $(CABAL) build $(CABAL_BUILD_FLAGS)
CABAL_INSTALL := $(CABAL) install $(CABAL_INSTALL_FLAGS)
update notebook build mechanisms
2015-02-06 03:12:36 +03:00
CS := $(HERE)/.cabal-sandbox
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
CS_BIN := $(CS)/bin
Initial import from internal repo
2014-04-18 02:34:25 +04:00
update WiX installer version Moved from 3.7 to 3.8, and also changed the Program Files path as we're using a 64-bit machine now on the build farm.
2014-10-17 01:51:46 +04:00
# Used only for windows, to find the right Program Files.
PROGRAM_FILES = Program\ Files\ \(x86\)
# Windows installer tools; assumes running on Cygwin and using WiX 3.8
WiX := /cygdrive/c/${PROGRAM_FILES}/WiX\ Toolset\ v3.8
Initial import from internal repo
2014-04-18 02:34:25 +04:00
CANDLE := ${WiX}/bin/candle.exe
HEAT := ${WiX}/bin/heat.exe
LIGHT := ${WiX}/bin/light.exe
change system description parameter in makefile
2014-04-24 06:36:41 +04:00
REV ?= $(shell git rev-parse --short=7 HEAD || echo "unknown")
VERSION := $(shell grep -i ^Version cryptol.cabal | awk '{ print $$2}')
SYSTEM_DESC ?= ${UNAME}-${ARCH}_${REV}
PKG := cryptol-${VERSION}-${SYSTEM_DESC}
Initial import from internal repo
2014-04-18 02:34:25 +04:00
# Windows-specific stuff
ifneq (,$(findstring _NT,${UNAME}))
DIST := ${PKG}.msi
EXE_EXT := .exe
adjust-path = '$(shell cygpath -w $1)'
distribution tweaks Makefile now has two modes depending on whether PREFIX is set. If it's not, we try to make the distribution as relocatable as possible, meaning we don't rely on the baked-in-by-cabal data directory. If it is set, we do use that path.
2015-03-04 03:22:14 +03:00
PREFIX ?=
# For a systemwide distribution .msi, use:
# PREFIX ?= ${PROGRAM_FILES}/Galois/Cryptol\ ${VERSION}
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
# split this up because `cabal copy` strips drive letters
PREFIX_ABS := /cygdrive/c/${PREFIX}
# since Windows installs aren't overlapping like /usr/local, we
# don't need this extra prefix
PREFIX_SHARE :=
# goes under the share prefix
PREFIX_DOC := /doc
PKG_PREFIX := ${PKG}/${PREFIX}
tweak to Makefile for Windows dist
2015-03-05 01:53:59 +03:00
ROOT_PATH := /cygdrive/c
Initial import from internal repo
2014-04-18 02:34:25 +04:00
else
DIST := ${PKG}.tar.gz ${PKG}.zip
EXE_EXT :=
adjust-path = '$1'
distribution tweaks Makefile now has two modes depending on whether PREFIX is set. If it's not, we try to make the distribution as relocatable as possible, meaning we don't rely on the baked-in-by-cabal data directory. If it is set, we do use that path.
2015-03-04 03:22:14 +03:00
PREFIX ?=
# For a systemwide distribution like an .rpm or .pkg, use something like:
# PREFIX ?= /usr/local
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
PREFIX_ABS := ${PREFIX}
PREFIX_SHARE := /share
# goes under the share prefix
PREFIX_DOC := /doc/cryptol
update notebook build mechanisms
2015-02-06 03:12:36 +03:00
PKG_PREFIX := ${PKG}${PREFIX}
tweak to Makefile for Windows dist
2015-03-05 01:53:59 +03:00
ROOT_PATH := /
Initial import from internal repo
2014-04-18 02:34:25 +04:00
endif
update notebook build mechanisms
2015-02-06 03:12:36 +03:00
CRYPTOL_EXE := ./dist/build/cryptol/cryptol${EXE_EXT}
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
Initial import from internal repo
2014-04-18 02:34:25 +04:00
.PHONY: all
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
all: ${CRYPTOL_EXE}
.PHONY: run
run: ${CRYPTOL_EXE}
CRYPTOLPATH=$(call adjust-path,$(CURDIR)/lib) ${CRYPTOL_EXE}
Initial import from internal repo
2014-04-18 02:34:25 +04:00
.PHONY: docs
docs:
(cd docs; make)
.PHONY: dist
dist: ${DIST}
.PHONY: tarball
tarball: ${PKG}.tar.gz
.PHONY: zip
zip: ${PKG}.zip
.PHONY: msi
msi: ${PKG}.msi
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
# TODO: piece this apart a bit more; if right now if something fails
# during initial setup, you have to invoke this target again manually
Initial import from internal repo
2014-04-18 02:34:25 +04:00
${CS}:
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
$(CABAL) sandbox init
Initial import from internal repo
2014-04-18 02:34:25 +04:00
${CS_BIN}/alex: | ${CS}
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
$(CABAL_INSTALL) alex
Initial import from internal repo
2014-04-18 02:34:25 +04:00
serialize alex and happy targets Fixes #161
2015-01-18 22:34:25 +03:00
${CS_BIN}/happy: | ${CS} ${CS_BIN}/alex
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
$(CABAL_INSTALL) happy
Initial import from internal repo
2014-04-18 02:34:25 +04:00
switch to TH solution for GitRev This helps with #18 and should also reduce the number of unnecessary recompiles that were triggered by the Makefile and/or cabal. The cabal build type is now Simple. Most of the complication in the TH.hs module is due to the various places the current git hash might be stored: 1. Detached HEAD: the hash is in `.git/HEAD` 2. On a branch or tag: the hash is in a file pointed to by `.git/HEAD` in a location like `.git/refs/heads` 3. On a branch or tag but in a repository with packed refs: the hash is in `.git/packed-refs` These situations all arise under normal development workflows and on the Jenkins build machines, but there might be further scenarios that cause problems. The tradeoff seems worthwhile though as now projects that build Cryptol as a dependency wind up having to rebuild Cryptol far less frequently.
2015-03-16 23:18:28 +03:00
GIT_INFO_FILES :=
ifneq ("$(wildcard .git/index)","")
GIT_INFO_FILES := ${GIT_INFO_FILES} .git/index
endif
ifneq ("$(wildcard .git/HEAD)","")
GIT_INFO_FILES := ${GIT_INFO_FILES} .git/HEAD
endif
ifneq ("$(wildcard .git/packed-refs)","")
GIT_INFO_FILES := ${GIT_INFO_FILES} .git/packed-refs
endif
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
CRYPTOL_SRC := \
start benchmarking suite with a Prelude parse test
2015-08-10 21:24:36 +03:00
$(shell find src cryptol cryptol-server bench \
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
\( -name \*.hs -or -name \*.x -or -name \*.y \) \
-and \( -not -name \*\#\* \) -print) \
switch to TH solution for GitRev This helps with #18 and should also reduce the number of unnecessary recompiles that were triggered by the Makefile and/or cabal. The cabal build type is now Simple. Most of the complication in the TH.hs module is due to the various places the current git hash might be stored: 1. Detached HEAD: the hash is in `.git/HEAD` 2. On a branch or tag: the hash is in a file pointed to by `.git/HEAD` in a location like `.git/refs/heads` 3. On a branch or tag but in a repository with packed refs: the hash is in `.git/packed-refs` These situations all arise under normal development workflows and on the Jenkins build machines, but there might be further scenarios that cause problems. The tradeoff seems worthwhile though as now projects that build Cryptol as a dependency wind up having to rebuild Cryptol far less frequently.
2015-03-16 23:18:28 +03:00
$(shell find lib -name \*.cry) \
${GIT_INFO_FILES}
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
Make the cryptol binary depend on the sources Instead of making the cryptol binary .PHONY, use find to locate all the sources to depend on.
2014-12-09 22:20:31 +03:00
print-%:
@echo $* = $($*)
clean up cryptol-server for merging
2015-07-21 21:52:17 +03:00
# If CRYPTOL_SERVER is nonempty, build the cryptol-server executable
ifneq (,${CRYPTOL_SERVER})
SERVER_FLAG := -fserver
endif
distribution tweaks Makefile now has two modes depending on whether PREFIX is set. If it's not, we try to make the distribution as relocatable as possible, meaning we don't rely on the baked-in-by-cabal data directory. If it is set, we do use that path.
2015-03-04 03:22:14 +03:00
# We do things differently based on whether we have a PREFIX set by
# the user. If we do, then we know the eventual path it'll wind up in
# (useful for stuff like RPMs or Homebrew). If not, we try to be as
# relocatable as possible.
ifneq (,${PREFIX})
PREFIX_ARG := --prefix=$(call adjust-path,${PREFIX_ABS})
DESTDIR_ARG := --destdir=${PKG}
tweak how the prelude is loaded This removes the `self-contained` flag, since it is fine for all builds to have the baked-in prelude as a last resort. Tinkerers can still change the prelude as long as it's in the search path. Also removes some unnecessary extra prelude loading by the Cryptol server by means of a new command
2015-11-16 23:56:36 +03:00
CONFIGURE_ARGS := -f-relocatable \
clean up cryptol-server for merging
2015-07-21 21:52:17 +03:00
--docdir=$(call adjust-path,${PREFIX}/${PREFIX_SHARE}/${PREFIX_DOC}) \
${SERVER_FLAG}
distribution tweaks Makefile now has two modes depending on whether PREFIX is set. If it's not, we try to make the distribution as relocatable as possible, meaning we don't rely on the baked-in-by-cabal data directory. If it is set, we do use that path.
2015-03-04 03:22:14 +03:00
else
# This is kind of weird: 1. Prefix argument must be absolute; Cabal
# doesn't yet fully support relocatable packages. 2. We have to
# provide *some* prefix here even if we're not using it, otherwise
# `cabal copy` will make a mess in the PKG directory.
clean up how license files are included in dist
2015-03-23 20:42:10 +03:00
PREFIX_ARG := --prefix=$(call adjust-path,${ROOT_PATH})
DESTDIR_ARG := --destdir=${PKG}
tweak how the prelude is loaded This removes the `self-contained` flag, since it is fine for all builds to have the baked-in prelude as a last resort. Tinkerers can still change the prelude as long as it's in the search path. Also removes some unnecessary extra prelude loading by the Cryptol server by means of a new command
2015-11-16 23:56:36 +03:00
CONFIGURE_ARGS := --docdir=$(call adjust-path,${PREFIX_SHARE}/${PREFIX_DOC}) \
clean up cryptol-server for merging
2015-07-21 21:52:17 +03:00
${SERVER_FLAG}
distribution tweaks Makefile now has two modes depending on whether PREFIX is set. If it's not, we try to make the distribution as relocatable as possible, meaning we don't rely on the baked-in-by-cabal data directory. If it is set, we do use that path.
2015-03-04 03:22:14 +03:00
endif
dist/setup-config: cryptol.cabal Makefile | ${CS_BIN}/alex ${CS_BIN}/happy
add server flag to deps install step
2015-07-28 23:30:20 +03:00
$(CABAL_INSTALL) --only-dependencies ${SERVER_FLAG}
distribution tweaks Makefile now has two modes depending on whether PREFIX is set. If it's not, we try to make the distribution as relocatable as possible, meaning we don't rely on the baked-in-by-cabal data directory. If it is set, we do use that path.
2015-03-04 03:22:14 +03:00
$(CABAL) configure ${PREFIX_ARG} --datasubdir=cryptol \
add "self-contained" mode for Cryptol-as-a-Library Many of our projects that depend on Cryptol break because we forgot to drag along `Cryptol.cry` or it just can't work out where it is from the perspective of the other executable. There's now a new flag `self-contained` in `cryptol.cabal` that is on by default that bakes the contents of the Prelude into the library, so that it can be reproduced on demand. This is really a hack at this point because the module system bakes in the assumption that a module has an associated file path, so we actually have to write the contents to a tmp file before reading them back in. Let's do better than this in the future. This option is disabled for targets in the Makefile because we want the standalone interpreter to be using the distribution's `Cryptol.cry`.
2015-03-06 02:14:09 +03:00
${CONFIGURE_ARGS}
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
switch to TH solution for GitRev This helps with #18 and should also reduce the number of unnecessary recompiles that were triggered by the Makefile and/or cabal. The cabal build type is now Simple. Most of the complication in the TH.hs module is due to the various places the current git hash might be stored: 1. Detached HEAD: the hash is in `.git/HEAD` 2. On a branch or tag: the hash is in a file pointed to by `.git/HEAD` in a location like `.git/refs/heads` 3. On a branch or tag but in a repository with packed refs: the hash is in `.git/packed-refs` These situations all arise under normal development workflows and on the Jenkins build machines, but there might be further scenarios that cause problems. The tradeoff seems worthwhile though as now projects that build Cryptol as a dependency wind up having to rebuild Cryptol far less frequently.
2015-03-16 23:18:28 +03:00
${CRYPTOL_EXE}: $(CRYPTOL_SRC) dist/setup-config
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
$(CABAL_BUILD)
PKG_BIN := ${PKG_PREFIX}/bin
PKG_SHARE := ${PKG_PREFIX}${PREFIX_SHARE}
PKG_CRY := ${PKG_SHARE}/cryptol
PKG_DOC := ${PKG_SHARE}${PREFIX_DOC}
PKG_EXAMPLES := ${PKG_DOC}/examples
PKG_EXCONTRIB := ${PKG_EXAMPLES}/contrib
PKG_EXAMPLE_FILES := docs/ProgrammingCryptol/aes/AES.cry \
docs/ProgrammingCryptol/enigma/Enigma.cry \
examples/DES.cry \
examples/Cipher.cry \
examples/DEStest.cry \
examples/Test.cry \
make notebook distributable This commit brings the notebook into the rest of the distribution infrastructure set up for cryptol. The main points are: - new icryptol-kernel executable - new icryptol shell script that wraps ipython and makes sure the cryptol profile is set up - Makefile target for friendly local testing (`make notebook`) - moved example notebooks to examples subdirectory
2015-02-12 03:21:43 +03:00
examples/SHA1.cry \
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
PKG_EXCONTRIB_FILES := examples/contrib/mkrand.cry \
examples/contrib/RC4.cry \
examples/contrib/simon.cry \
examples/contrib/speck.cry
Revert to the original makefile
2015-09-30 00:04:57 +03:00
${PKG}: ${CRYPTOL_EXE} \
clean up how license files are included in dist
2015-03-23 20:42:10 +03:00
docs/*.md docs/*.pdf LICENSE LICENSE.rtf \
make notebook distributable This commit brings the notebook into the rest of the distribution infrastructure set up for cryptol. The main points are: - new icryptol-kernel executable - new icryptol shell script that wraps ipython and makes sure the cryptol profile is set up - Makefile target for friendly local testing (`make notebook`) - moved example notebooks to examples subdirectory
2015-02-12 03:21:43 +03:00
${PKG_EXAMPLE_FILES} ${PKG_EXCONTRIB_FILES}
Revert to the original makefile
2015-09-30 00:04:57 +03:00
$(CABAL) copy ${DESTDIR_ARG}
mkdir -p ${PKG_CRY}
mkdir -p ${PKG_DOC}
mkdir -p ${PKG_EXAMPLES}
mkdir -p ${PKG_EXCONTRIB}
cp docs/*.md ${PKG_DOC}
cp docs/*.pdf ${PKG_DOC}
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
for EXAMPLE in ${PKG_EXAMPLE_FILES}; do \
Revert to the original makefile
2015-09-30 00:04:57 +03:00
cp $$EXAMPLE ${PKG_EXAMPLES}; done
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
for EXAMPLE in ${PKG_EXCONTRIB_FILES}; do \
cp $$EXAMPLE ${PKG_EXCONTRIB}; done
clean up how license files are included in dist
2015-03-23 20:42:10 +03:00
# cleanup unwanted files
# don't want to bundle the cryptol library in the binary distribution
rm -rf ${PKG_PREFIX}/lib; rm -rf ${PKG_PREFIX}/*windows-ghc*
clean up doc distribution
2015-03-25 23:25:32 +03:00
# don't ship haddock
rm -rf ${PKG_DOC}/html
Initial import from internal repo
2014-04-18 02:34:25 +04:00
add an install target meant to make distribution with, eg., Homebrew an easier task
2015-03-04 04:21:29 +03:00
.PHONY: install
install: ${PKG}
[ -n "${PREFIX}" ] \
|| (echo "[error] Can't install without PREFIX set"; false)
(cd ${PKG_PREFIX}; \
find . -type d -exec install -d ${PREFIX}/{} \; ; \
find bin -not -type d -exec install -m 755 {} ${PREFIX}/{} \; ; \
find share -not -type d -exec install -m 644 {} ${PREFIX}/{} \;)
Initial import from internal repo
2014-04-18 02:34:25 +04:00
${PKG}.tar.gz: ${PKG}
tar -czvf $@ $<
${PKG}.zip: ${PKG}
zip -r $@ $<
${PKG}.msi: ${PKG} win32/cryptol.wxs
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
${HEAT} dir ${PKG_PREFIX} -o allfiles.wxs -nologo -var var.pkg \
-ag -wixvar -cg ALLFILES -srd -dr INSTALLDIR -sfrag
${CANDLE} -ext WixUIExtension -ext WixUtilExtension \
-dversion=${VERSION} -dpkg=${PKG_PREFIX} win32/cryptol.wxs
${CANDLE} -ext WixUIExtension -ext WixUtilExtension \
-dversion=${VERSION} -dpkg=${PKG_PREFIX} allfiles.wxs
${LIGHT} -ext WixUIExtension -ext WixUtilExtension \
-sval -o $@ cryptol.wixobj allfiles.wixobj
Initial import from internal repo
2014-04-18 02:34:25 +04:00
rm -f allfiles.wxs
rm -f *.wixobj
rm -f *.wixpdb
${CS_BIN}/cryptol-test-runner: \
Revert to the original makefile
2015-09-30 00:04:57 +03:00
${PKG} \
Initial import from internal repo
2014-04-18 02:34:25 +04:00
$(CURDIR)/tests/Main.hs \
$(CURDIR)/tests/cryptol-test-runner.cabal
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
$(CABAL_INSTALL) ./tests
Initial import from internal repo
2014-04-18 02:34:25 +04:00
.PHONY: test
Revert to the original makefile
2015-09-30 00:04:57 +03:00
test: ${CS_BIN}/cryptol-test-runner
Initial import from internal repo
2014-04-18 02:34:25 +04:00
( cd tests && \
echo "Testing on $(UNAME)-$(ARCH)" && \
$(realpath $(CS_BIN)/cryptol-test-runner) \
Modify testrunniner to figure out on its own if we have a dir or a test. This means we don't need -d anymore, and now we can run individual tests from the comman line.
2015-02-26 01:19:11 +03:00
$(TESTS) \
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
-c $(call adjust-path,${CURDIR}/${PKG_BIN}/cryptol${EXE_EXT}) \
Initial import from internal repo
2014-04-18 02:34:25 +04:00
-r output \
-T --hide-successes \
-T --jxml=$(call adjust-path,$(CURDIR)/results.xml) \
Allow expected failures to be ignored
2015-03-31 02:58:33 +03:00
$(IGNORE_EXPECTED) \
Allow `make test` to output the diff results
2014-12-06 03:49:58 +03:00
$(if $(TEST_DIFF),-p $(TEST_DIFF),) \
Initial import from internal repo
2014-04-18 02:34:25 +04:00
)
start benchmarking suite with a Prelude parse test
2015-08-10 21:24:36 +03:00
# Since this is meant for development rather than end-user builds,
# this tries to stay out of the way of the other targets by
# reconfiguring, then removing dist/setup-config so that other targets
# aren't left in a weird state
.PHONY: bench
bench: cryptol.cabal Makefile | ${CS_BIN}/alex ${CS_BIN}/happy
$(CABAL_INSTALL) --only-dependencies --enable-benchmarks
$(CABAL) configure --enable-benchmarks
add junit-style output for `make bench` target
2015-08-13 01:47:50 +03:00
$(CABAL) bench --benchmark-option=--junit --benchmark-option=$(call adjust-path,$(CURDIR)/bench.xml)
start benchmarking suite with a Prelude parse test
2015-08-10 21:24:36 +03:00
rm -rf dist/setup-config
Initial import from internal repo
2014-04-18 02:34:25 +04:00
.PHONY: clean
clean:
cabal clean
rm -f $(CS_BIN)/cryptol-test-suite
rm -rf cryptol-${VERSION}*/
rm -rf cryptol-${VERSION}*.tar.gz
rm -rf cryptol-${VERSION}*.zip
rm -rf cryptol-${VERSION}*.msi
.PHONY: squeaky
squeaky: clean
Fixes #172 There's now a more sensible hierarchy of locations that Cryptol uses to look for modules. By default, in order it looks for libraries in: 1. The directories specified in the CRYPTOLPATH environment variable 2. The current directory 3. The user data directory (something like `$HOME/.cryptol`) 4. Relative to the executable's install directory 5. The static path used when building the executable (cabal's data-dir) There is also a new command-line flag for the interpreter: `--cryptolpath-only` which makes the interpreter ignore locations 2-5. This commit also reworks the Makefile and build/release process. These are bunched together because they play off each other quite a bit; the build/release process determines the location of the `Cryptol.cry`, which must be found when looking for modules. Rather than leaning on `cabal install`, we now use a combination of `cabal configure`, `cabal build`, and `cabal copy`. A couple of upshots to this: - More of the release staging is handled by cabal -- we don't have to go in and manually copy things out of the sandbox. In fact, the `cryptol` executable never goes into the sandbox. - The testing infrastructure runs on executables that are in place in the staging directory, rather than in the sandbox. This should be more hygienic and realistic. - The `Cryptol.cry` prelude file is now in `/share/cryptol` in order to better reflect the common POSIX structure. This means Cryptol will play nicer in global installs, and mirrors what other interpreted languages do. - The default build settings use a prefix of `/usr/local` rather than using the sandbox directory. This makes them more relocatable for binary distributions. Set PREFIX= before making to change this.
2015-01-22 02:03:16 +03:00
-$(CABAL) sandbox delete
Revert to the original makefile
2015-09-30 00:04:57 +03:00
(cd docs; make clean)
Initial import from internal repo
2014-04-18 02:34:25 +04:00
rm -rf dist
rm -rf tests/dist
Reference in New Issue Copy Permalink