Created attachment 220313 [details] Patch for pcre2 * Update pcre2 to 10.36 * Add main site as fallback in case sourceforge mirrors are unavailable * Use DISTVERSION instead of PORTVERSION as per "Table 5.2. Package Naming Examples" in porters handbook * Switch to tar.bz2 archive, ~25% reduction in size * Switch to CMake, significantly reduces compilation time [1] * Add "hidden" option to set MATCH_LIMIT_DEPTH * Define _USES before ARGS for consistency References: [1] Tested on 13-CURRENT (amd64), Intel i7-3770k Autotools: ====> Compressing man pages (compress-man) 1m0.95s real 2m31.33s user 6.26s sys CMake: ====> Compressing man pages (compress-man) 31.00s real 1m7.34s user 1.95s sys Compile tested on FreeBSD 13.0-CURRENT #0 r367711 (amd64) (make, make check-plist, make test) Poudriere testport OK 12.2-RELEASE (amd64) (with and without (lib)readline Poudriere testport OK 11.4-RELEASE (amd64) (with and without (lib)readline Additional notes: This change doesn't install static lib(s) by default, I can't find any port that makes use of it in the tree.
Created attachment 220468 [details] Patch for pcre2 v2 Refresh patch, make use of CMAKE_ON and _OFF macros
Created attachment 220611 [details] Patch for pcre2 v3 Cosmetic fix to Makefile, reviewed by tcb@
What is the rationale to use cmake in this case, improving compiling time by some seconds looks like a microoptimization for me, don't forget cmake itself takes almost 1h to build, so I'd rather stay with current pcre2 dependencies
Hi, I first want to apologize for the late reply, I simply forgot sorry :/ I agree that CMake on its own for pcre2 might seem like an odd move however many projects are transitioning to either CMake or Meson so moving the dependency one level further down shouldn't be much of a deal looking at the big picture. We currently have roughly 3k ports using CMake and more are transitioning from GNU Autotools. CMake is usually also considered easier to use, more cross-compiler friendly and easier to debug overall. If we also can cut compilation time that's a nice bonus. While it's not an official statement there also seems to be a general desire to move away from GNU Autotools in general for ports. As for compiling CMake I did a few tests, it compiles much faster than 1h unless you're possibly using an ARM-based SBC. Intel Pentium G3220 (3.0Ghz, 1 job) 18m5.15s real 17m23.35s user 37.21s sys RockPro64 (4x A53 @ 1.4GHz utilizing all cores) 46m19.51s real 2h49m3.86s user 5m58.92s sys Best regards, Daniel
although the time was effectively halved, this isn't about "a few seconds" the thing that often takes the longest in VM autotools based build is running configure, a task that cannot be parallelised, and that shells out a million times, often asking the same questions over and over again. moving to cmake isn't about shaving off a few seconds of build time, it's about saving hours of developer and maintainer time, because while writing and maintaining and debugging a single ten line sh script is easy, debugging thousands of lines of shell is - not impossible, but very, very tedious.