GH753: More spelling fix

     The "unified" build system is aimed to be a common system for all

     platforms we support.  With it comes new support for VMS.

     This system builds supports building in a differnt directory tree

     This system builds supports building in a different directory tree

     than the source tree.  It produces one Makefile (for unix family

     or lookalikes), or one descrip.mms (for VMS).

#   more sense?

# - Keep in mind that the HP compiler by default generates code

#   suitable for execution on the host you're currently compiling at.

#   If the toolkit is ment to be used on various PA-RISC processors

#   If the toolkit is meant to be used on various PA-RISC processors

#   consider './Configure hpux-parisc-[g]cc +DAportable'.

# - -DMD32_XARRAY triggers workaround for compiler bug we ran into in

#   32-bit message digests. (For the moment of this writing) HP C

#   chew forever:-). For more details look-up MD32_XARRAY comment in

#   crypto/sha/sha_lcl.h.

# - originally there were 32-bit hpux-parisc2-* targets. They were

#   scrapped, because a) they were not interchangable with other 32-bit

#   scrapped, because a) they were not interchangeable with other 32-bit

#   targets; a) when critical 32-bit assembly modules detect if they

#   are executed on PA-RISC 2.0 and thus adequate performance is

#   provided. 

    'inherit_from' that indicate what other configurations to inherit

    data from.  These are resolved recursively.

    Inheritance works as a set of default values that can be overriden

    Inheritance works as a set of default values that can be overridden

    by corresponding key values in the inheriting configuration.

    Note 1: any configuration table can be used as a template.

                  'lib' has the intended library file name *without*

                  extension, libobj2shlib is expected to add that.

                  'shlib' has the correcponding shared library name

                  'shlib' has the corresponding shared library name

                  *without* extension.  'deps' has the list of other

                  libraries (also *without* extension) this library

                  needs to be linked with.  'objs' has the list of

directory.

Make sure to end the section with these functions with a string that

you thing is apropriate for the resulting build file.  If nothing

you thing is appropriate for the resulting build file.  If nothing

else, end it like this:

      "";       # Make sure no lingering values end up in the Makefile

few possible exceptions [1]) have information about end products (such

as scripts, library files and programs) and source files (such as C

files, C header files, assembler files, etc).  Intermediate files such

as object files are rarely directly refered to in build.info files (and

as object files are rarely directly referred to in build.info files (and

when they are, it's always with the file name extension .o), they are

infered by Configure.  By the same rule of minimalism, end product

inferred by Configure.  By the same rule of minimalism, end product

file name extensions (such as .so, .a, .exe, etc) are never mentioned

in build.info.  Their file name extensions will be infered by the

in build.info.  Their file name extensions will be inferred by the

build-file templates, adapted for the platform they are meant for (see

sections on %unified_info and build-file templates further down).

Two things are worth an extra note:

'DEPEND[cversion.o]' mentiones an object file.  DEPEND indexes is the

'DEPEND[cversion.o]' mentions an object file.  DEPEND indexes is the

only location where it's valid to mention them

Lines in 'BEGINRAW'..'ENDRAW' sections must always mention files as

            },

    );

As can be seen, everything in %unified_info is fairly simple nuggest

As can be seen, everything in %unified_info is fairly simple suggest

of information.  Still, it tells us that to build all programs, we

must build 'apps/openssl', and to build the latter, we will need to

build all its sources ('apps/openssl.o' in this case) and all the

                  'lib' has the intended library file name *without*

                  extension, libobj2shlib is expected to add that.

                  'shlib' has the correcponding shared library name

                  'shlib' has the corresponding shared library name

                  *without* extension.  'deps' has the list of other

                  libraries (also *without* extension) this library

                  needs to be linked with.  'objs' has the list of

/*

 * The usage is quite simple, initialize an ASN1 structure, get a BIO from it

 * then any data written through the BIO will end up translated to

 * approptiate format on the fly. The data is streamed out and does *not*

 * appropriate format on the fly. The data is streamed out and does *not*

 * need to be all held in memory at once. When the BIO is flushed the output

 * is finalized and any signatures etc written out. The BIO is a 'proper'

 * BIO and can handle non blocking I/O correctly. The usage is simple. The