ENGINE modules aren't special, so call them MODULES

[openssl.git] / Configurations / README

diff --git a/Configurations/README b/Configurations/README
index c1f80fe49e8db90e528b0a3df7561aaca3af0e1a..8efabb37aa741959bb50019f3d80423064662fb2 100644 (file)
--- a/Configurations/README
+++ b/Configurations/README
@@ -118,7 +118,7 @@ In each table entry, the following keys are significant:
                            '<unistd.h>'.  This is very rarely needed.
 
         shared_extension => File name extension used for shared
-                            libraries. 
+                            libraries.
         obj_extension   => File name extension used for object files.
                            On unix, this defaults to ".o" (NOTE: this
                            is here for future use, it's not
@@ -159,7 +159,7 @@ In each table entry, the following keys are significant:
                            below [2].
         dso_scheme      => The type of dynamic shared objects to build
                            for.  This mostly comes into play with
-                           engines, but can be used for other purposes
+                           modules, but can be used for other purposes
                            as well.  Valid values are "DLFCN"
                            (dlopen() et al), "DLFCN_NO_H" (for systems
                            that use dlopen() et al but do not have
@@ -350,7 +350,7 @@ In each table entry, the following keys are significant:
 
     - shared libraries; that would be libcrypto and libssl.
     - shared objects (sometimes called dynamic libraries);  that would
-      be the engines.
+      be the modules.
     - applications; those are apps/openssl and all the test apps.
 
     Very roughly speaking, linking is done like this (words in braces
@@ -411,11 +411,10 @@ variables:
 
     PROGRAMS=foo bar
     LIBS=libsomething
-    ENGINES=libeng
+    MODULES=libeng
     SCRIPTS=myhack
-    EXTRA=file1 file2
 
-Note that the files mentioned for PROGRAMS, LIBS and ENGINES *must* be
+Note that the files mentioned for PROGRAMS, LIBS and MODULES *must* be
 without extensions.  The build file templates will figure them out.
 
 For each thing to be built, it is then possible to say what sources
@@ -486,48 +485,6 @@ be used in that case:
 
 NOTE: GENERATE lines are limited to one command only per GENERATE.
 
-As a last resort, it's possible to have raw build file lines, between
-BEGINRAW and ENDRAW lines as follows:
-
-    BEGINRAW[Makefile(unix)]
-    haha.h: {- $builddir -}/Makefile
-        echo "/* haha */" > haha.h
-    ENDRAW[Makefile(unix)]
-
-The word within square brackets is the build_file configuration item
-or the build_file configuration item followed by the second word in the
-build_scheme configuration item for the configured target within
-parenthesis as shown above.  For example, with the following relevant
-configuration items:
-
-   build_file   => "build.ninja"
-   build_scheme => [ "unified", "unix" ]
-
-... these lines will be considered:
-
-   BEGINRAW[build.ninja]
-   build haha.h: echo "/* haha */" > haha.h
-   ENDRAW[build.ninja]
-
-   BEGINRAW[build.ninja(unix)]
-   build hoho.h: echo "/* hoho */" > hoho.h
-   ENDRAW[build.ninja(unix)]
-
-Should it be needed because the recipes within a RAW section might
-clash with those generated by Configure, it's possible to tell it
-not to generate them with the use of OVERRIDES, for example:
-
-    SOURCE[libfoo]=foo.c bar.c
-    
-    OVERRIDES=bar.o
-    BEGINRAW[Makefile(unix)]
-    bar.o: bar.c
-       $(CC) $(CFLAGS) -DSPECIAL -c -o $@ $<
-    ENDRAW[Makefile(unix)]
-
-See the documentation further up for more information on configuration
-items.
-
 Finally, you can have some simple conditional use of the build.info
 information, looking like this: