[packaging] libapr README url fix patch

Dale Lukas Peterson hazelnusse at gmail.com
Thu Apr 4 16:03:37 UTC 2019

Hi Boris,
 I updated my branch with your suggestions. I wasn't aware of Clara until
you mentioned it. Regarding whether we should bundle the one that is
checked in to the catch2 repo or leave that separate, the latter seems most
logical to me. Clara isn't strictly required to use catch2, so forcing a
particular version upon people would probably make it annoying for them to
use different versions due to include path problems. As far as testing
goes, there is a bit of chicken and egg problem here -- catch.hpp is
checked into the repo, but to test a commit, you need to run the python
script that creates catch.hpp then run the tests on that generated file,
not the one that is checked in. I'll take a closer look at the existing
CMake infrastructure (there is also conan infrastructure) but if you have
time and want to run with it, feel free to do so. I think in this
situation, it may make sense to declare the dependency on clara explicitly
with build2, so that clara doesn't need to be copy-pasta'd into catch2.
This latter approach seems like the *right* thing to do, but certainly more
work since it means build2-ifying clara, though perhaps not really that
much since clara is also a header only library.


On Thu, Apr 4, 2019 at 3:56 AM Boris Kolpackov <boris at codesynthesis.com>

> 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).

For a successful technology, reality must take precedence over public
relations, for Nature cannot be fooled. -- Richard Feynman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/packaging/attachments/20190404/90e4c57c/attachment.html>

More information about the packaging mailing list