# I have created a small abstraction library for PCRE2 compatiblity \[zig-pcre\] this is absolutely stable accross new versions of Zig

**URL:** <https://ziggit.dev/t/i-have-created-a-small-abstraction-library-for-pcre2-compatiblity-zig-pcre-this-is-absolutely-stable-accross-new-versions-of-zig/17693>\
**Category:** Showcase\
**Tags:** language, c, build-system, zig-0-16\
**Created:** [September 23, 2026, 7:36pm UTC](https://ziggit.dev/t/i-have-created-a-small-abstraction-library-for-pcre2-compatiblity-zig-pcre-this-is-absolutely-stable-accross-new-versions-of-zig/17693 "2026-09-23T19:36:46Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![rminol](https://ziggit.dev/user_avatar/ziggit.dev/rminol/32/10186_2.png) [@rminol](https://ziggit.dev/u/rminol)\
**Post date:** [September 23, 2026, 7:36pm UTC](https://ziggit.dev/t/i-have-created-a-small-abstraction-library-for-pcre2-compatiblity-zig-pcre-this-is-absolutely-stable-accross-new-versions-of-zig/17693/1 "2026-09-23T19:36:46Z")

</div>

# zig-pcre:

Hi Community,

I was developing a web application using http.zig (Purely from @karlseguin). At one moment, I wanted to validate user inputs using regular expressions. I searched the internet for most widely used and fast regular expression engines and found PCRE2.

To make things easier I wrote a simple abstraction over libpcre2 wrapping with Zig code. I saw that libpcre2 has it’s own `build.zig`. But wanted to omit that since PCRE2’s own `CmakeLists.txt` battle tested for years. Their own team maintain a stable `CmakeLists.txt` Cmake based build mechanism than PCRE2’s own `build.zig`.

`build.zig` is a moving target since Zig language is in it’s development stage (I’m pretty sure Zig is at the edge of it’s journey becoming v1.0. Even if it is not Zig feels stable). Instead of relying 100% on `build.zig` for compiling pcre2 library .c source files, I triggered PCRE2’s `CmakeLists.txt` cmake build mechanism keeping `libpcre2` as a git submodule via `b.addSystemCommand()`. And linked final `libpcre.a` to the mdoule code written in Zig.

If the `zig-pcre` design fully depend on `build.zig`, build issues may arise when compiling with the new versions of zig releases and it will take some time to apply the changes for `zig-pcre` to be compatible with new Zig versions. But making `build.zig` shorter and harnessing the power of cmake build, I let PCRE2 to build by itself.

Additionally for the cmake compile I used `zig cc` and `zig c++` as compillers. By doing this I’m 100% sure whatever `.a` comes out can co-exist with Zig code with no other compiler involvement.

This is one of the most iconic advantage in Zig; It’s ability to pack everything into a single static binary so that the final executable can run anywhere. With This ability, Zig can compete with **Go-ficators** and **Rusti-ficators**.

I know this `zig-pcre` may not be adopted by majority but with this little approach I wish there will be no room for **[other hype based language]-ficators** to play and Ziguana ecosystem will be more stable and powerfull.

[https://codeberg.org/rishithaminol/zig-pcre](https://codeberg.org/rishithaminol/zig-pcre)

* * *

### Supported Zig versions

0.16.0  
0.17.0-dev and onwards

### AI / LLM usage disclosure

AI was not used in this project. Specially there are no vibe-coded particles.  
Since my knowledge on English is moderate level, I had to use AI for preparing some parts of README.md to express what in my mind.

---

<div class="post-metadata">

**Author:** ![nullndvoid](https://ziggit.dev/user_avatar/ziggit.dev/nullndvoid/32/9181_2.png) [@nullndvoid](https://ziggit.dev/u/nullndvoid)\
**Post date:** [September 29, 2026, 9:16am UTC](https://ziggit.dev/t/i-have-created-a-small-abstraction-library-for-pcre2-compatiblity-zig-pcre-this-is-absolutely-stable-accross-new-versions-of-zig/17693/2 "2026-09-29T09:16:44Z")

</div>

Thanks this is very cool. I think it’s usually suggested to use build.zig but yeah it can be a bit of a moving target between releases so I understand why you stuck with submodule + usual CMake build.

---

<div class="post-metadata">

**Author:** ![rminol](https://ziggit.dev/user_avatar/ziggit.dev/rminol/32/10186_2.png) [@rminol](https://ziggit.dev/u/rminol)\
**Post date:** [September 29, 2026, 11:47am UTC](https://ziggit.dev/t/i-have-created-a-small-abstraction-library-for-pcre2-compatiblity-zig-pcre-this-is-absolutely-stable-accross-new-versions-of-zig/17693/3 "2026-09-29T11:47:45Z")

</div>

Most of the common C libraries we have very stable. It may take some time for original developers to bring same library written in Zig.  
But if we use Zig as our compiler and instruct Cmake to use it as CC compiler to generate .a file we can statically link it into the final Zig binary.
