Bug 251642 - devel/pcre2: Switch to CMake and minor Makefile cleanups
Summary: devel/pcre2: Switch to CMake and minor Makefile cleanups
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kirill Ponomarev
URL: https://vcs.pcre.org/pcre2/code/trunk...
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-06 14:43 UTC by daniel.engberg.lists
Modified: 2021-01-21 09:56 UTC (History)
1 user (show)

See Also:
bugzilla: maintainer-feedback? (krion)


Attachments
Patch for pcre2 (6.40 KB, patch)
2020-12-06 14:43 UTC, daniel.engberg.lists
no flags Details | Diff
Patch for pcre2 v2 (6.37 KB, patch)
2020-12-11 22:41 UTC, daniel.engberg.lists
no flags Details | Diff
Patch for pcre2 v3 (6.37 KB, patch)
2020-12-16 08:51 UTC, daniel.engberg.lists
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description daniel.engberg.lists 2020-12-06 14:43:24 UTC
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.
Comment 1 daniel.engberg.lists 2020-12-11 22:41:24 UTC
Created attachment 220468 [details]
Patch for pcre2 v2

Refresh patch, make use of CMAKE_ON and _OFF macros
Comment 2 daniel.engberg.lists 2020-12-16 08:51:24 UTC
Created attachment 220611 [details]
Patch for pcre2 v3

Cosmetic fix to Makefile, reviewed by tcb@
Comment 3 Kirill Ponomarev freebsd_committer 2020-12-16 09:19:43 UTC
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
Comment 4 daniel.engberg.lists 2021-01-03 08:50:47 UTC
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
Comment 5 Mina Galić 2021-01-21 09:56:22 UTC
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.