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
528a7d516d
cryptol/Makefile

238 lines
7.4 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)
Add the mono-binds flag When `:set mono-binds=on`, any local definitions lacking type signatures will not be generalized (i.e., will be monomorphic). This reduces what is in most cases unnecessary polymorphism that can give rise to constraints that are difficult to solve. This also improves the performance of the Cryptol interpreter by lifting many polymorphic type applications out of the inner loops that are commonly defined as bindings in `where` clauses. The flag is on by default in the Cryptol REPL, and in most cases makes it possible to leave out more type signatures in `where` clauses than before. However, some programs really do rely on inferring polymorphic types for local variables; in this case adding an explicit polymorphic type signature to the local binding in question will make the program typecheck.
2014-12-16 04:48:25 +03:00
TESTS ?= 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
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}
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}
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
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 := \
$(shell find src cryptol \
\( -name \*.hs -or -name \*.x -or -name \*.y \) \
-and \( -not -name \*\#\* \) -print) \
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
$(shell find lib -name \*.cry)
tweak how often we generate GitRev.hs
2015-03-04 03:27:40 +03:00
src/GitRev.hs:
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
sh configure
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 $* = $($*)
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}
RELOCATABLE_ARG := -f-relocatable
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.
PREFIX_ARG := --prefix=/
DESTDIR_ARG := --destdir=${PKG}
RELOCATABLE_ARG :=
endif
dist/setup-config: cryptol.cabal Makefile | ${CS_BIN}/alex ${CS_BIN}/happy
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) --only-dependencies
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 \
${RELOCATABLE_ARG}
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 out notebook into separate package This involved: - Moving a couple REPL modules into the Cryptol library hierarchy (those that don't depend on console libraries) - Splitting up the Makefile, which unfortunately resulted in a lot of not-quite-duplication between the two Makefiles. Let's look into better abstraction...
2015-03-03 02:46:21 +03:00
${CRYPTOL_EXE}: $(CRYPTOL_SRC) src/GitRev.hs 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
split out notebook into separate package This involved: - Moving a couple REPL modules into the Cryptol library hierarchy (those that don't depend on console libraries) - Splitting up the Makefile, which unfortunately resulted in a lot of not-quite-duplication between the two Makefiles. Let's look into better abstraction...
2015-03-03 02:46:21 +03:00
${PKG}: ${CRYPTOL_EXE} \
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
docs/*.md docs/*.pdf LICENSE \
${PKG_EXAMPLE_FILES} ${PKG_EXCONTRIB_FILES}
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) copy ${DESTDIR_ARG}
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
# script not included in the copy
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
# don't want to bundle the cryptol library in the binary distribution
rm -rf ${PKG_PREFIX}/lib
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}
cp LICENSE ${PKG_DOC}
for EXAMPLE in ${PKG_EXAMPLE_FILES}; do \
cp $$EXAMPLE ${PKG_EXAMPLES}; done
for EXAMPLE in ${PKG_EXCONTRIB_FILES}; do \
cp $$EXAMPLE ${PKG_EXCONTRIB}; done
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: \
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} \
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
test: ${CS_BIN}/cryptol-test-runner
( 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 `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
)
.PHONY: clean
clean:
cabal clean
rm -f src/GitRev.hs
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
Initial import from internal repo
2014-04-18 02:34:25 +04:00
(cd docs; make clean)
rm -rf dist
rm -rf tests/dist
Reference in New Issue Copy Permalink