GaloisInc/cryptol
1
1
Fork 0
mirror of https://github.com/GaloisInc/cryptol.git synced 2024-12-16 20:03:27 +03:00
Code Issues Projects Releases Wiki Activity
4fb370c8ec
cryptol/Makefile

212 lines
6.3 KiB
Makefile
Raw Normal View History

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)
CS := ./.cabal-sandbox
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)'
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 ?= ${PROGRAM_FILES}/Galois/Cryptol\ ${VERSION}
# 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'
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 ?= /usr/local
PREFIX_ABS := ${PREFIX}
PREFIX_SHARE := /share
# goes under the share prefix
PREFIX_DOC := /doc/cryptol
PKG_PREFIX := ${PKG}${PREFIX}
Initial import from internal repo
2014-04-18 02:34:25 +04:00
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_EXE := ./dist/build/cryptol/cryptol${EXE_EXT}
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)
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
src/GitRev.hs: .git/index
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 $* = $($*)
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
# /usr/share/cryptol on POSIX, installdir/cryptol on Windows
DATADIR := ${PREFIX_ABS}${PREFIX_SHARE}
configuration depends on cryptol.cabal
2015-02-17 01:40:24 +03:00
dist/setup-config: cryptol.cabal | ${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
$(CABAL) configure \
--prefix=$(call adjust-path,${PREFIX_ABS}) \
--datasubdir=cryptol
${CRYPTOL_EXE}: $(CRYPTOL_SRC) src/GitRev.hs dist/setup-config
$(CABAL_BUILD)
# ${CS_BIN}/cryptolnb: ${CS_BIN}/alex ${CS_BIN}/happy | ${CS}
# $(CABAL) install . -fnotebook
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 \
examples/SHA1.cry
PKG_EXCONTRIB_FILES := examples/contrib/mkrand.cry \
examples/contrib/RC4.cry \
examples/contrib/simon.cry \
examples/contrib/speck.cry
${PKG}: ${CRYPTOL_EXE}
$(CABAL) copy --destdir=${PKG}
# 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
${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) \
$(foreach t,$(TESTS),-d $t) \
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
)
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
# .PHONY: notebook
# notebook: ${CS_BIN}/cryptolnb
# cd notebook && ./notebook.sh
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