[packaging] libapr README url fix patch

Thu Apr 4 16:09:46 UTC 2019

Oh neat, clara depends on catch2 and has also an older copy (v2.1) checked
in to the source repo:
https://github.com/catchorg/Clara/blob/master/third_party/catch.hpp

A gift that keeps on giving!

Sort of reminds me of the time a co-worker zipped up the repository
(including the .git directory), and then checked that in to the
repository.... sigh. Turtles all the way down
<https://en.wikipedia.org/wiki/Turtles_all_the_way_down>.

Luke

On Thu, Apr 4, 2019 at 9:03 AM Dale Lukas Peterson <hazelnusse at gmail.com>
wrote:

> 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.
>
> Luke
>
> On Thu, Apr 4, 2019 at 3:56 AM Boris Kolpackov <boris at codesynthesis.com>
> wrote:
>
>> 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
>

-- 
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/9313b159/attachment-0001.html>