Compiling PCRE on non-Unix systems----------------------------------This document contains the following sections:  General  Generic instructions for the PCRE C library  The C++ wrapper functions  Building for virtual Pascal  Stack size in Windows environments  Comments about Win32 builds  Building PCRE with CMake  Building under Windows with BCC5.5  Building PCRE on OpenVMSGENERALI (Philip Hazel) have no experience of Windows or VMS sytems and how theirlibraries work. The items in the PCRE distribution and Makefile that relate toanything other than Unix-like systems are untested by me.There are some other comments and files in the Contrib directory on the ftpsite that you may find useful. See  ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ContribIf you want to compile PCRE for a non-Unix system (especially for a system thatdoes not support "configure" and "make" files), note that the basic PCRElibrary consists entirely of code written in Standard C, and so should compilesuccessfully on any system that has a Standard C compiler and library. The C++wrapper functions are a separate issue (see below).The PCRE distribution includes support for CMake. This support is relativelynew, but has already been used successfully to build PCRE in multiple buildenvironments on Windows. There are some instructions in the section entitled"Building PCRE with CMake" below.GENERIC INSTRUCTIONS FOR THE PCRE C LIBRARYThe following are generic comments about building the PCRE C library "by hand". (1) Copy or rename the file config.h.generic as config.h, and edit the macro     settings that it contains to whatever is appropriate for your environment.     In particular, if you want to force a specific value for newline, you can     define the NEWLINE macro. When you compile any of the PCRE modules, you     must specify -DHAVE_CONFIG_H to your compiler so that config.h is included     in the sources.     An alternative approach is not to edit config.h, but to use -D on the     compiler command line to make any changes that you need to the     configuration options. In this case -DHAVE_CONFIG_H must not be set.     NOTE: There have been occasions when the way in which certain parameters     in config.h are used has changed between releases. (In the configure/make     world, this is handled automatically.) When upgrading to a new release,     you are strongly advised to review config.h.generic before re-using what     you had previously. (2) Copy or rename the file pcre.h.generic as pcre.h. (3) EITHER:       Copy or rename file pcre_chartables.c.dist as pcre_chartables.c.     OR:       Compile dftables.c as a stand-alone program (using -DHAVE_CONFIG_H if       you have set up config.h), and then run it with the single argument       "pcre_chartables.c". This generates a set of standard character tables       and writes them to that file. The tables are generated using the default       C locale for your system. If you want to use a locale that is specified       by LC_xxx environment variables, add the -L option to the dftables       command. You must use this method if you are building on a system that       uses EBCDIC code.     The tables in pcre_chartables.c are defaults. The caller of PCRE can     specify alternative tables at run time. (4) Ensure that you have the following header files:       pcre_internal.h       ucp.h       ucpinternal.h       ucptable.h (5) Also ensure that you have the following file, which is #included as source     when building a debugging version of PCRE and is also used by pcretest.       pcre_printint.src (6) Compile the following source files, setting -DHAVE_CONFIG_H as a compiler     option if you have set up config.h with your configuration, or else use     other -D settings to change the configuration as required.       pcre_chartables.c       pcre_compile.c       pcre_config.c       pcre_dfa_exec.c       pcre_exec.c       pcre_fullinfo.c       pcre_get.c       pcre_globals.c       pcre_info.c       pcre_maketables.c       pcre_newline.c       pcre_ord2utf8.c       pcre_refcount.c       pcre_study.c       pcre_tables.c       pcre_try_flipped.c       pcre_ucp_searchfuncs.c       pcre_valid_utf8.c       pcre_version.c       pcre_xclass.c     Make sure that you include -I. in the compiler command (or equivalent for     an unusual compiler) so that all included PCRE header files are first     sought in the current directory. Otherwise you run the risk of picking up     a previously-installed file from somewhere else. (7) Now link all the compiled code into an object library in whichever form     your system keeps such libraries. This is the basic PCRE C library. If     your system has static and shared libraries, you may have to do this once     for each type. (8) Similarly, compile pcreposix.c (remembering -DHAVE_CONFIG_H if necessary)     and link the result (on its own) as the pcreposix library. (9) Compile the test program pcretest.c (again, don't forget -DHAVE_CONFIG_H).     This needs the functions in the pcre and pcreposix libraries when linking.     It also needs the pcre_printint.src source file, which it #includes.(10) Run pcretest on the testinput files in the testdata directory, and check     that the output matches the corresponding testoutput files. Note that the     supplied files are in Unix format, with just LF characters as line     terminators. You may need to edit them to change this if your system uses     a different convention. If you are using Windows, you probably should use     the wintestinput3 file instead of testinput3 (and the corresponding output     file). This is a locale test; wintestinput3 sets the locale to "french"     rather than "fr_FR", and there some minor output differences.(11) If you want to use the pcregrep command, compile and link pcregrep.c; it     uses only the basic PCRE library (it does not need the pcreposix library).THE C++ WRAPPER FUNCTIONSThe PCRE distribution also contains some C++ wrapper functions and tests,contributed by Google Inc. On a system that can use "configure" and "make",the functions are automatically built into a library called pcrecpp. It shouldbe straightforward to compile the .cc files manually on other systems. Thefiles called xxx_unittest.cc are test programs for each of the correspondingxxx.cc files.BUILDING FOR VIRTUAL PASCALA script for building PCRE using Borland's C++ compiler for use with VPASCALwas contributed by Alexander Tokarev. Stefan Weber updated the script and addedadditional files. The following files in the distribution are for building PCREfor use with VP/Borland: makevp_c.txt, makevp_l.txt, makevp.bat, pcregexp.pas.STACK SIZE IN WINDOWS ENVIRONMENTSThe default processor stack size of 1Mb in some Windows environments is toosmall for matching patterns that need much recursion. In particular, test 2 mayfail because of this. Normally, running out of stack causes a crash, but therehave been cases where the test program has just died silently. See your linkerdocumentation for how to increase stack size if you experience problems. TheLinux default of 8Mb is a reasonable choice for the stack, though even that canbe too small for some pattern/subject combinations.PCRE has a compile configuration option to disable the use of stack forrecursion so that heap is used instead. However, pattern matching issignificantly slower when this is done. There is more about stack usage in the"pcrestack" documentation.COMMENTS ABOUT WIN32 BUILDS (see also "BUILDING PCRE WITH CMAKE" below)There are two ways of building PCRE using the "configure, make, make install"paradigm on Windows systems: using MinGW or using Cygwin. These are not at allthe same thing; they are completely different from each other. There is alsosome experimental, undocumented support for building using "cmake", which youmight like to try if you are familiar with "cmake". However, at the presenttime, the "cmake" process builds only a static library (not a dll), and thetests are not automatically run.The MinGW home page (http://www.mingw.org/) says this:  MinGW: A collection of freely available and freely distributable Windows  specific header files and import libraries combined with GNU toolsets that  allow one to produce native Windows programs that do not rely on any  3rd-party C runtime DLLs.