Remove makecleantest

.gitignore

 Clean System Files/
 cleantest
-makecleantest

Makefile

-BIN:=cleantest makecleantest
+BIN:=cleantest
 CLM:=clm
-CLMFLAGS:=-nr -nt -h 100m -nortsopts\
-	-IL ArgEnv\
-	-IL Platform\
-	-I Cloogle\
-	-I Cloogle/libcloogle\
-	-I Cloogle/CleanPrettyPrint\
-	-I Cloogle/CleanRegex\
-	-I Cloogle/CleanTypes\
-	-I Cloogle/clean-compiler/frontend\
-	-I Cloogle/clean-compiler/backend\
-	-I Cloogle/clean-compiler/main\
-	-I Cloogle/clean-compiler/main/Unix
+CLMFLAGS:=-nr -nt -h 100m -nortsopts -IL Platform
 
 .PHONY: all clean
 
 all: $(BIN)
 
-$(BIN): Cloogle/clean-compiler .FORCE
+$(BIN): .FORCE
 	$(CLM) $(CLMFLAGS) $@ -o $@
 
-Cloogle/clean-compiler:
-	$(MAKE) -C Cloogle clean-compiler
-
 clean:
 	$(RM) -r **/Clean\ System\ Files $(BIN)
 

README.md

 # clean-test [![pipeline status](https://gitlab.science.ru.nl/clean-and-itasks/clean-test/badges/master/pipeline.svg)](https://gitlab.science.ru.nl/clean-and-itasks/clean-test/commits/master)
 
-This projects hosts tools that can be used to test Clean programs.
-The available tools are:
-
-- `cleantest` which can run test programs
-- `makecleantest` which can generate test programs from dcl modules
-
-## cleantest
-
 This tool can run other test programs and combine the results.
 The tool was conceived in
 [clean-platform#17](https://gitlab.science.ru.nl/clean-and-itasks/clean-platform/issues/19).
@@ -36,82 +28,3 @@ cleantest -r testModuleA -r testModuleB
 
 The tool has several command-line options; check `cleantest --help` for
 up-to-date details.
-
-## makecleantest
-
-This tool can generate test programs using [Gast][]'s `exposeProperties` (see
-above) from dcl modules. The properties to test are described in [CleanDoc][]
-blocks: comments above function types. This works as follows:
-
-- On the module documentation block, add a `@property-bootstrap` field. This
-  field should contain the 'header' of the generated test program: required
-  imports and helper definitions. The programmer must not add a module header
-  (`definition module ...`) and does not need to import Gast modules or the
-  module under test itself.
-
-- On each function to test, add one or more `@property` fields to the docblock.
-  This property for now always starts with `A.`, followed by a number of
-  parameters and their types. The first line ends with a colon `:`. The
-  implementation of the property follows on the next line(s). For example:
-
-  ```clean
-  /**
-   * @property member_correct: A.x :: a; xs :: [a]:
-   *   member x (fromList xs) <==> isMember x xs
-   */
-  member :: !a !(Set a) -> Bool | < a
-  ```
-
-  Note that one can use Gast's `<==>` here without import, nor does one need to
-  import the module itself for `member` (and `fromList`). However, `isMember`
-  requires `import StdList` in the `@property-bootstrap` of the module.
-
-  It is possible to use multiple lines for the implementation of the property.
-  `makecleantest` will guess the right indentation level.
-
-- When parameters in `@property` fields contain type variables, the programmer
-  is required to suggest types to instantiate these variables with when
-  testing &mdash; otherwise, how would Gast be able to generate test cases?
-  This can be done with `@property-test-with`, either locally on the function
-  docblock or globally on the module docblock. For example:
-
-  ```clean
-  /**
-   * @property-test-with a = Int
-   * @property-test-with a = Real
-   */
-  ```
-
-  For all relevant tests using the type variable `a`, two versions will be
-  generated: one with `Int` and one with `Real`. When multiple type variables
-  are used, all combinations are tested.
-
-- Sometimes, Gast's generic test generation method is not very useful. This is
-  for instance the case with types for which automatically generated values are
-  not 'valid'.
-
-  Take `Set a` as an example. It is possible to write tests on `[a]` instead,
-  then in every test use `fromList :: [a] -> Set a` to get the set. However,
-  this is not very modular, and also clutters up the properties.
-
-  What you can do instead is writing tests as you would normally do,
-  quantifying over `Set a` in the property signature, and then add a
-  `@property-test-generator` to the module. This field tells the test generator
-  how to generate values of a certain type. An example is:
-
-  ```clean
-  /**
-   * @property-test-generator [a] -> Set a | < a
-   *   gen xs = fromList xs
-   */
-  ```
-
-  Currently, only generators with arity 1 are supported (but this can be worked
-  around using a tuple or an auxiliary data type in the `@property-bootstrap`).
-  When the generator has class constraints, you are expected to resolve them
-  yourself by providing the required instances, depending on the type variable
-  instantiations.
-
-
-[Gast]: https://gitlab.science.ru.nl/clean-and-itasks/gast
-[CleanDoc]: https://github.com/clean-cloogle/Cloogle#clean-documentation