[packaging] libapr README url fix patch

[Boris Kolpackov]

Dale Lukas Peterson <hazelnusse at gmail.com> writes:

> I wanted to start with something simple and wanted to get a unit testing
> library in place before I do any significant work using build2. To this
> end, I was thinking that packaging Catch2 would be a good idea.

Good idea. These days every second C++ project seems to be bundling their
own copy so it would be nice to have a package for it.


> Up-streaming the changes would probably be preferred, but more difficult
> to socialize.

Phil was actually interested in build2. I've just asked him if he would
be interesting in adding build2 support. Will let you know when I hear
back.


> I couldn't find a unit testing framework that is already packaged with
> build2, other than the built in test module, which I think serves a
> different purposes, though perhaps I'm mistaken.

Right, the test module (and its Testscript language) is a test runner,
not a testing framework for a particular programming language. It does
not concern itself with how the test executables themselves are
implemented. As a result, it is mostly geared towards functional
testing but can also be used for unit testing if external input/output
is required.


> Is the libapr1 package a good example of how to package an existing
> library, or do you recommend I look at something different?

Good question. I should write the "Packaging Existing Projects" guide
at some point, once we have a bit more experience. In the meantime:

libapr2 is not really a good example since it is a "stub" (a package
without any source code and which can only be "obtained" from the
system).

At this stage the best example for Catch2 (which is a header-only
library with the "headers go to the include/ subdirectory" setup),
would probably be my PR for Boost.Predef:

https://github.com/boostorg/predef/pull/95

This assumes Phil says yes and we go the upstreaming route.

Otherwise, we can package it non-intrusively. The current "state
of the art" example for this approach is our OpenSSL package:

https://git.build2.org/cgit/packaging/openssl/openssl/

Note that this package (actually packages) is a lot more complex
than what would likely be required for Catch2. It does, however,
show some handy techniques like pulling upstream source as a git
submodule and then using symlinks to reorganize/overlay the
upstream source with build2 support (the accompanying README-DEV
file has more details).

The nicest thing about the non-intrusive approach is that you
can often "fix" upstream's mistakes (from our point of view,
anyways) rather than fighting them.

So, based on this, I would suggest that we wait to hear from Phil
and then decide on the course of action.