Added support for (CMake) Unity Builds.

[pkeir]

The modifications allow a unity (jumbo) build by renaming an enum member (RANGE_STARTED); adding #undef for NLBLOCK, PSSTART, and PSEND at the end of the (three) units where they are defined; and renaming two of the three do_callout definitions.

CMake can then be used to create a unity build as shown:

cmake -DCMAKE_UNITY_BUILD=ON ..

[zherczeg]

You have explained what you did, but not the why. These are internal defines, should not affect other libs / programs.

[pkeir]

In general, I find it convenient to have the option there, to use unity builds (often they are faster), so I thought it might be a good addition to PCRE2.

[carenas]

to use unity builds (often they are faster), so I thought it might be a good addition to PCRE2.

while I doubt a unity build of PCRE2 would be faster than a regular build with Ninja or even make, the change itself seems sensible and unlikely to do any harm (except maybe by the odd renaming of the pcre2_convert enum and the ongoing maintenance).

@pkeir: could you elaborate better in the rationale to understand if breaking that is worth the tradeoff?, for example that enum that was renamed could had been deleted as well, and the way the codebase is structured, there are a lot more unusual includes (ex: pcre2_jit_compile.c includes another c file inside sljit that includes several other files) so the scope of macros is not as straight forward as you would expect in applications that only include headers with well defined APIs.

[pkeir]

@carenas Apologies for the delay, I missed the notification.

I would firstly suggest that a CMake unity build can also be a default option for some developers; regardless of whether the build speed is improved. For those users, it will be a reassurance, as (rightly or wrongly) the option of a unity build can be an indicator of good code hygiene.

As for the details of the commit: indeed, the enum could have been removed rather than renamed. I chose a conservative route to allow a simple translation for imagined authors of pending PCRE2 modules. I would otherwise support its removal.

In fact, reviewing the changes again reminds me that a grep for RANGE_STARTED produces results, which for a newcomer, could unexpectedly have come from either of two different enums.

I note the include of sljitLir.c in pcre2_jit_compile.c you mention. I can only say that I also built with JIT enabled, and all of the test sets passed as before; plus extra passes for the enabled JIT feature tests (including pcre2_jit_test).

One last thought is that unity builds can also simplify some integration tasks; for example when compiling as a C++ constexpr module, or a GPGPU program.

[PhilipHazel]

OK, as @carenas says, this change doesn't look harmful. I will shortly merge it, but then I am going to remove the unused enum, which must be an oversight, and I'm also going to add comments to remind me (or anyone else) why there are #undefs at the end of modules. I will experiment with a unity build under Linux, and if that's easy, add it to my list of pre-release tests, because I can see how easy it would be to break this by accident.