Re: [PATCH] gnu: Add capnproto.

[Kenton Varda]

On Thu, Aug 25, 2016 at 7:57 AM, Marius Bakke <address@hidden> wrote:
> Hi, thanks for dropping in!
>
> From reading the comments in the Makefile, apparently they are trying to
> enforce something called the One-Definition Rule:
>
> https://en.wikipedia.org/wiki/One_Definition_Rule
>
> The way Guix (and actually most distro build systems) works makes it
> impossible for another definition to "leak" into the build container, so
> I don't understand either what they are trying to solve.

I think what they're actually referring to here is issues with
templates that are instantiated in the same way in different places --
the instances need to be de-duped. When shared libraries are involved,
this gets weird, and Windows and OSX both tend to have severe
problems. Linux/ELF generally "gets it right" by using weak symbols,
although that relies on the fact that symbols in shared libraries all
get lumped into one process-wide symbol table with no namespacing,
which causes a bunch of other problems... but it's great at handling
ODR correctly.

So I think the gtest people may actually be concerned about problems
that primarily affect other platforms and they have applied an
over-broad policy.

Another possibility is that they have severe ABI compatibility issues,
perhaps caused by #ifdefs in template definitions, in which case
linking gtest as a library would fail miserably if the app chose
different flags than gtest itself.

But again, I am mostly speculating and could be wrong.

> I think Kenton is referring to the Debian manual, which is in XML
> format:
>
> https://github.com/thomaslee/capnproto-debian/blob/master/debian/capnp.1.xml
>
> But you are right, it would be better to convert it to a standard format
> and simply add a make target for it.

Right, my main point here is that I would like the help text to be the
canonical source of documentation, with other sources being
auto-generated from it. The nice thing about the help text is that the
kj::Main framework actually makes it very hard to forget to update the
help text, since it forces you to provide documentation for each flag
when defining them. So when the code changes, the help text always
gets updated, whereas a separate document probably won't because I am
incredibly lazy. :)

In theory, it should be easy even for someone with poor C++ skills to
copy the existing code that generates --help then modify it to
generate some other format instead. ;)

In any case, I'll definitely mention it on the issue you opened (which
I actually hadn't seen yet -- email overload).

-Kenton