[packaging] libapr README url fix patch
boris at codesynthesis.com
Thu Apr 4 10:56:24 UTC 2019
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:
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)?
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
Hm, but we should install the single-file version, correct? In other words,
multi-file version is in a sense internal.
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
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?
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
Ok, let us try and see how it goes.
One more question: in the packaging case it probably makes sense to treat
`external/clara.hpp` as a separate package on which `catch2` depends?
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
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.
Well that was the idea - Catch’s use of Clara should be independent of
That’s usually where transitive dependencies fall down
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.
How does it solve the problem?
Which problem are you referring to? ;-)
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
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.
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
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?
in theory, yes
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
> 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
More information about the packaging