Add PCRE support for regular expressions into tests

[9fcc]

I've added support in both cmake and autoconf.
PCRE can be enabled using --enable-pcreposix=yes and disabled using --enable-pcreposix=no with configure or enabled using -DWITH_PCREPOSIX=1 and disabled using -DWITH_PCREPOSIX=0 with cmake. In all other cases it must be detected automatically.

[9fcc]

Well, cmake doesn't find pcreposix. As I think path to PCRE directory must be provided. So probably I'll try to use environment variables from powershell to CMake. For now I don't see another solution because Windows do not have standard directories.

[brarcher]

Is this line necessary, as getting here implies ENABLE_REGEX==0

[brarcher]

Could you add the following commit to this request: dcf59ad. That should install PCRE for a CMake build. You could then add the following to get a test working for autotools:

   - if %platform%==mingw32 appveyor-retry nuget install pcre -Verbosity detailed -OutputDirectory C:\pcre
   - if %platform%==mingw32 cmake -G "MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=%P%
   - if %platform%==mingw64msys set PATH=C:\msys64\mingw64\bin;C:\msys64\usr\bin;%PATH%
+  - if %platform%==mingw64msys appveyor-retry nuget install pcre -Verbosity detailed -OutputDirectory C:\pcre
   - if %platform%==mingw64msys bash -c "autoreconf -i"
   - if %platform%==mingw64msys bash -c "./configure"

This will leave at least one autotools and CMake build that does not find PCRE.

Well, cmake doesn't find pcreposix. As I think path to PCRE directory must be provided.

The nuget package manager lets one define the install directory for PCRE. Currently in dcf59ad it is being set to C:\pcre. However, feel free to change this to whatever is convenient.

[9fcc]

Could you add the following commit to this request: dcf59ad.

Ok, but some later. I'll have to make some experiments.

Do you know what the common practice is for Windows? Do I need to install libraries into build directory? Or can cmake find them automatically somehow? The only thing I found is the cmake registry. If some project was build from source cmake writes about it to the registry so it can be found as dependency. But there is no nuget support in CMake.

By the way, linking with subunit library was the example for me. But there is no tests for Windows with it.

[brarcher]

Do you know what the common practice is for Windows?

Unfortunately, I do not know. From the questions I have fielded, it appears that users of Check build Check along with the source of a project and its unit tests, instead of installing it on the system for re-use. Though, I admit, my sample size is low.

[brarcher]

Here is an example that a developer brought to my attention from the civetweb project. For that project the Check framework is downloaded and compiled during the build from its CMake files to ${CMAKE_BINARY_DIR}/third_party, where CMAKE_BINARY_DIR is the top level of the current CMake build tree.

[9fcc]

I already saw similar solutions. People build static libraries and link against them. Or they had to copy libraries into installer if they build them as dinamyc. That's because of DLL hell as I've figured out.

[9fcc]

@brarcher How can I get access with RDP to AppVeyor?

[brarcher]

The following shows what to add to the appveyor.yml file to start RDP during a build:

https://www.appveyor.com/docs/how-to/rdp-to-build-worker/

You will need to start a build, then look at the logs as the test is running. In the logs will be information about what address to access as well as username/password.

[brarcher]

Do you have access to the logs while the build is running? If not, I wonder if you will need to setup a AppVeyor account and run builds against your fork.

[brarcher]

Have you been able to make further progress on this? Are you still interested in pursuing this?

[9fcc]

Sorry, I'll continue to contribute a little later. I had some changes in my life and at the moment most of my time goes to my family.

[ladar]

From the questions I have fielded, it appears that users of Check build Check along with the source of a project and its unit tests, instead of installing it on the system for re-use. Though, I admit, my sample size is low.

As an anecdote... I started out using the system version of libcheck, but eventually switched to a bundled format because I wanted to take advantage of functions/macros that were part of the latest version, and thus not available from the system package version. I also didn't want the checks to break everytime somebody tried compiling on a different distro, with yet another version.

As for this pull request. I was wondering whether your using libpcre-posix.{so,a} or the posix regular expression functions (regcomp/regexec/regerror/regfree)? I know the perl syntax is easier to use, but the posix functions are more likely to be available/work across platforms.

[9fcc]

Check uses POSIX regular expressions in its tests so yes, libpcre-posix can be used on Windows systems. This pull request is only for compiling all the tests on Windows systems to ensure floating macros work on Windows too. It doesn't affect the library.

The problem is that I am not experienced Windows programmer and even have no Windows copy on my laptop so I need to find out where pcre is installed in Windows and prepare CMake file for adding packaged Windows libraries. But my free time is very fragmented so I can't concentrate on long-time tasks that need preparations. This pull request is like a reminder for me that I have unfinished task and any help would be appreciated.