[packaging] libapr README url fix patch
Dale Lukas Peterson
hazelnusse at gmail.com
Fri Apr 5 14:46:59 UTC 2019
On Fri, Apr 5, 2019 at 3:22 AM Boris Kolpackov <boris at codesynthesis.com>
> Hi Luke,
> Dale Lukas Peterson <hazelnusse at gmail.com> writes:
> > > I updated my branch with your suggestions. I wasn't aware of Clara
> > > 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
> > > logical to me. Clara isn't strictly required to use catch2, so forcing
> > > particular version upon people would probably make it annoying for
> them to
> > > use different versions due to include path problems.
> While I agree it would make more sense to have Clara as a separate
> dependency of Catch2, from our chat it's clear Phil feels strongly
> about having a private copy and the reasons he gives do make sense
> (essentially, making sure Catch2 uses a known-compatible version
> of Clara while not forcing the users to use the same version).
> Since they are doing all the work of making sure that such a
> "private Clara" does not conflict with "user Clara", I think we
> should respect their wishes and just bundle it.
I agree this is the most rational choice at the moment. I would enjoy
discussing the hypothetical situation of how this would be solved if
starting from scratch with build2.
> > > 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
> > > the python script that creates catch.hpp then run the tests on that
> > > generated file, not the one that is checked in.
> Hm, that sounds surprising (or perhaps my email was confusing): I think
> the Python script is required to generate single_include/catch.hpp from
> all the headers in include/. Our (new) plan, however, is to ignore
> single_include/ entirely and always use include/, including installing
> the multi-header variant.
I could be wrong, but it looks from the travis build that the
single_include is built, then cmake is invoked from the root dir -- thus
using the single include. You can have a look here:
The source of truth for this is:
So the source of truth of the header is really the include directories like
you mentioned. If for some reason the generated single header was different
from the one that is committed (for example due to environment or Python
differences), then what is tested (generated single header) is not the same
as what is committed.
I saw your build2 branch on your catch2 fork and look forward to seeing
this come to a conclusion so I can start using build2 for some projects :)
> > > [...] if you have time and want to run with it, feel free to do so.
> Ok, let me take a quick stab at it to at least get one test building.
> Will ping you when push.
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...
More information about the packaging