[packaging] libapr README url fix patch

[Boris Kolpackov]

Hi Luke,

Nice to see you are back at it! I looked over your changes and have a
couple of overall comments:

- We don't need to touch root .gitignore (because of the alt naming scheme).

- In build2/.gitignore, then first line should be 'config.build2'

- I would suggest we call the project (in bootstrap.build) and package
  (in manifest) catch2 (lower case C). Lower-case names are our preferred
  naming scheme similar to Debian/RedHat package names.


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

> I don't think I have fully wrapped my head around bulid2 so I probably have
> something not quite correct. In particular I don't know if I've got the
> export.build2 stuff correct or quite how to test it. I think probably I
> need to create a simple application that depends on catch2, following the
> example in the manual and see if what I've done works correctly?

Yes, I was also looking for tests in Catch2 and decided to ask Phil. Here
is the transcript of our chat:

boris:
  Hi Phil, am I correct in assuming that Catch2 tests are in
  `projects/SelfTest/` and that they are compatible with the single-file
  variant (i.e., `single_include/` is sufficient to build them)?
  
philsquared:
  yes and no ;-)
  they are in SelfTest
  The self test _project_ works against the multi-file version
  
  but I did some work a year or two ago to separate out the test files that
  can work against the single header. I don’t remember, off-hand can check) if
  there’s a project that does that
  
boris:
  Hm, but we should install the single-file version, correct? In other words,
  multi-file version is in a sense internal.
  
philsquared:
  yes, although we may be making that available (again) as a first class way
  of consuming the library
  
  esp. in a package manager world where the benefits of single-header are less
  which is a separate discussion - but I’d be keen to hear your thoughts on
  that, too

boris:
  Yes, I think for packaging it doesn't make much difference whether it is
  a single heard or a bunch. And having two variants of using the library
  adds extra complexity. So maybe for `build2` we should just go ahead and
  do multi-file from the beginning? What do you think?

philsquared:
  I’ll need to check where Martin and co. are with that (Martin is driving
  that) - whether it is likely to involve any changes to the project structure
  but, assuming it won’t be fragile, yes

boris:
  Ok, let us try and see how it goes.

boris:
  One more question: in the packaging case it probably makes sense to treat
  `external/clara.hpp` as a separate package on which `catch2` depends?
  
philsquared:
  if going with the multi-file lib, yes actually
  technically yes - but that may require some thinking part of the embedding 
  process is including Clara in such a way that it is independent of other
  uses of Clara (e.g. if the app under test uses Clara directly, itself) I’m
  not sure if that would continue to “just work” or would need more thought
  probably safer, to begin with, to continue to use it embedded

boris:
  Does this "embedding process" also applies to the multi-header case?
  I also don't see any issues with both Catch2 and the application sharing
  the same Clara package unless for some reason Catch requires very specific
  version and which is also not what everyone else wants to use.

philsquared:
  Well that was the idea - Catch’s use of Clara should be independent of
  anyone else’s
  That’s usually where transitive dependencies fall down

boris:
  Why can't Catch and Application use the same version of Clara? The main
  point of package management is to sort all this out so that we don't need
  to have private dependencies.

philsquared:
  How does it solve the problem?
  
boris:
  Which problem are you referring to? ;-)

philsquared:
  The one where you end up using a version of a dependency you haven’t tested
  against which could (a) not compile or (b) compile but with incorrect
  behaviour

boris:
  If that's the concern, we can restrict the version constraint in the
  dependency to be 1.1.* or even 1.1.5 if required. My point is that
  unless Catch2 needs to use a version of Clara that for some reason is
  unpalatable to most other user, I don't see a reason to have a private copy.
  
philsquared:
  Catch2 needs to use the version of Clara that it was written against.
  Upgrading dependencies needs to be a carefully planned process that
  involves testing - and sometimes changes. Forcing other dependencies,
  or dependants, to upgrade with you is just not practical. And that’s
  not specific to Catch2 or Clara. It’s always been one of the biggest
  problems in dependency management

boris:
  Ok, I may not agree, but I see your point. So if we include
  `external/clara.hpp` with the multi-header variant, then everything
  should be good, right?

philsquared:
  in theory, yes

boris:
  Ok, let us try and see. After all this is what CI and tests are for ;-)  


So, as you can see, the rabbit hole is a bit deeper than we thought and
we should probably try to switch to the multi-header variant. This way
we will be able to build and run tests which we can make a sub-project
to also test the export stub (as well as the installed case).

Let me know if you feel like this is too much and I can help out or take
over ;-).


> I do have 2 questions:
> 1) the pkgconfig files have the following lines:
> Libs: -L/tmp/install/lib
> Is this desired for header only libraries?

Yes, we don't need it for a header-only library itselt, but it may be
necessary to resolve its source-full dependencies.


> 2) I made the name in the manifest as well as the project in the
> boostrap.build both be Catch2. Experimentally it seems that the project =
> Catch2 from bootstrap.build is used to name the directory where the
> LICENSE.txt, manifest, and README.md go. I was a bit confused by this and
> wonder if you could explain when you might have different values for the
> name and the project?

They should normally be the same. The reason we have it in two places is
because (1) there could be un-packages projects that only use the build
system (so we need it in bootstrap.build) and (2) it's good to have this
easily accessible as part of the package meta-information (so we have it
in manifest).