[PATCH] gnu: Add capnproto.

[PATCH] gnu: Add capnproto.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

Hi,

This adds the Cap'n Proto serialization system.

Note that it bundles googletest; I tried unbundling but it proved
difficult. gtest will no longer be used from the 0.6 release so I did
not think a comment was necessary.

-- Marius


[-- Attachment #2: 0001-gnu-Add-capnproto.patch --]
[-- Type: text/x-patch, Size: 3191 bytes --]

From 456e8242259061693f592d70529ff141b00ea7b1 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Sat, 13 Aug 2016 19:01:49 +0100
Subject: [PATCH] gnu: Add capnproto.

* gnu/packages/capnproto.scm: New file.
* gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
---
 gnu/local.mk               |  1 +
 gnu/packages/capnproto.scm | 48 ++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 49 insertions(+)
 create mode 100644 gnu/packages/capnproto.scm

diff --git a/gnu/local.mk b/gnu/local.mk
index 44ace61..846c8d7 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -62,6 +62,7 @@ GNU_SYSTEM_MODULES =				\
   %D%/packages/busybox.scm			\
   %D%/packages/c.scm				\
   %D%/packages/calcurse.scm			\
+  %D%/packages/capnproto.scm			\
   %D%/packages/ccache.scm			\
   %D%/packages/cdrom.scm			\
   %D%/packages/certs.scm			\
diff --git a/gnu/packages/capnproto.scm b/gnu/packages/capnproto.scm
new file mode 100644
index 0000000..bcd6d42
--- /dev/null
+++ b/gnu/packages/capnproto.scm
@@ -0,0 +1,48 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2016 Marius Bakke <mbakke@fastmail.com>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu packages capnproto)
+  #:use-module ((guix licenses) #:prefix license:)
+  #:use-module (guix packages)
+  #:use-module (guix download)
+  #:use-module (guix build-system gnu))
+
+(define-public capnproto
+  (package
+    (name "capnproto")
+    (version "0.5.3")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "https://capnproto.org/capnproto-c++-"
+                    version ".tar.gz"))
+              (sha256
+               (base32
+                "1yvaadhgakskqq5wpv53hd6fc3pp17mrdldw4i5cvgck4iwprcfd"))
+              (modules '((guix build utils)))
+              (snippet
+               ;; Workaround for test that tries to resolve port name from
+               ;; /etc/services, which is not present in build environment.
+               '(substitute* "src/kj/async-io-test.c++" ((":http") ":80")))))
+    (build-system gnu-build-system)
+    (home-page "https://capnproto.org")
+    (synopsis "Capability-based RPC and serialization system")
+    (description
+     "Cap'n Proto is a very fast data interchange format and capability-based RPC
+system.  Think JSON, except binary.  Or think Protocol Buffers, except faster.")
+    (license license:expat)))
-- 
2.9.2

Re: [PATCH] gnu: Add capnproto.

[Leo Famulari]

On Sat, Aug 13, 2016 at 07:48:36PM +0100, Marius Bakke wrote:
> Note that it bundles googletest; I tried unbundling but it proved
> difficult. gtest will no longer be used from the 0.6 release so I did
> not think a comment was necessary.

I am cc-ing Lukas with my reply, since he added our googletest package.
Maybe he has some insight.

> * gnu/packages/capnproto.scm: New file.
> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.

How about putting it in serialization.scm? There is protobuf.scm, but
that predates the serialization module.

> +              (snippet
> +               ;; Workaround for test that tries to resolve port name from
> +               ;; /etc/services, which is not present in build environment.
> +               '(substitute* "src/kj/async-io-test.c++" ((":http") ":80")))))


Origin snippets affect the result of `guix build --source`, and I think
their use should be limited to fixing critical bugs or software freedom
problems. This is working around a peculiarity of our build system, so I
think we should do it in a build phase, with modify-phases.

Can you send an updated patch?

Otherwise it looks good. Let's wait a couple days to see if anyone has
any advice about googletest.

Re: [PATCH] gnu: Add capnproto.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]

Leo Famulari <leo@famulari.name> writes:

> On Sat, Aug 13, 2016 at 07:48:36PM +0100, Marius Bakke wrote:
>> Note that it bundles googletest; I tried unbundling but it proved
>> difficult. gtest will no longer be used from the 0.6 release so I did
>> not think a comment was necessary.
>
> I am cc-ing Lukas with my reply, since he added our googletest package.
> Maybe he has some insight.
The problem is that their autotools system expects to build gtest as
well, so there are references all over. See:
https://github.com/sandstorm-io/capnproto/blob/release-0.5.3/c%2B%2B/Makefile.am
and also configure.ac. It would have to be patched out, which seems
excessive for a 4MB build dependency.

>> * gnu/packages/capnproto.scm: New file.
>> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.
>
> How about putting it in serialization.scm?
Oops, missed that. Thanks.

>> +              (snippet
>> +               ;; Workaround for test that tries to resolve port name from
>> +               ;; /etc/services, which is not present in build environment.
>> +               '(substitute* "src/kj/async-io-test.c++" ((":http") ":80")))))
>
>
> Origin snippets affect the result of `guix build --source`, and I think
> their use should be limited to fixing critical bugs or software freedom
> problems. This is working around a peculiarity of our build system, so I
> think we should do it in a build phase, with modify-phases.
That makes sense, thanks for the clarification. Please find updated
patch below.

-- Marius


[-- Attachment #2: 0001-gnu-Add-capnproto.patch --]
[-- Type: text/x-patch, Size: 2251 bytes --]

From 6672014e1b6018dcdf0286daa5624d5095e1c6b1 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Sat, 13 Aug 2016 19:01:49 +0100
Subject: [PATCH] gnu: Add capnproto.

* gnu/packages/serialization.scm (capnproto): New variable.
---
 gnu/packages/serialization.scm | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/gnu/packages/serialization.scm b/gnu/packages/serialization.scm
index 42bb2b8..ec1d6ed 100644
--- a/gnu/packages/serialization.scm
+++ b/gnu/packages/serialization.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2015 Ricardo Wurmus <rekado@elephly.net>
 ;;; Copyright © 2016 Lukas Gradl <lgradl@openmailbox.org>
+;;; Copyright © 2016 Marius Bakke <mbakke@fastmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -123,3 +124,32 @@ such as compact binary encodings, XML, or JSON.")
     (description "Msgpack is a library for C/C++ that implements binary
 serialization.")
     (license license:boost1.0)))
+
+(define-public capnproto
+  (package
+    (name "capnproto")
+    (version "0.5.3")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "https://capnproto.org/capnproto-c++-"
+                    version ".tar.gz"))
+              (sha256
+               (base32
+                "1yvaadhgakskqq5wpv53hd6fc3pp17mrdldw4i5cvgck4iwprcfd"))))
+    (build-system gnu-build-system)
+    (arguments
+     `(#:phases
+       (modify-phases %standard-phases
+         (add-before 'check 'do-not-require-/etc/services
+           (lambda _
+             ;; Workaround for test that tries to resolve port name from
+             ;; /etc/services, which is not present in build environment.
+             (substitute* "src/kj/async-io-test.c++" ((":http") ":80"))
+             #t)))))
+    (home-page "https://capnproto.org")
+    (synopsis "Capability-based RPC and serialization system")
+    (description
+     "Cap'n Proto is a very fast data interchange format and capability-based
+RPC system.  Think JSON, except binary.  Or think Protocol Buffers, except faster.")
+    (license license:expat)))
-- 
2.9.2

Re: [PATCH] gnu: Add capnproto.

[Leo Famulari]

On Sun, Aug 14, 2016 at 07:16:22PM +0100, Marius Bakke wrote:
> Leo Famulari <leo@famulari.name> writes:
> 
> > On Sat, Aug 13, 2016 at 07:48:36PM +0100, Marius Bakke wrote:
> >> Note that it bundles googletest; I tried unbundling but it proved
> >> difficult. gtest will no longer be used from the 0.6 release so I did
> >> not think a comment was necessary.
> >
> > I am cc-ing Lukas with my reply, since he added our googletest package.
> > Maybe he has some insight.
> The problem is that their autotools system expects to build gtest as
> well, so there are references all over. See:
> https://github.com/sandstorm-io/capnproto/blob/release-0.5.3/c%2B%2B/Makefile.am
> and also configure.ac. It would have to be patched out, which seems
> excessive for a 4MB build dependency.

In my opinion, it's generally not about the size of the bundled
dependency. Rather, it's about the opacity of the dependency graph of
the application that does the bundling. The worst case would be
something like a bundled OpenSSL, for example.

In this case, Debian has accepted the bundled gtest [0], which makes me
wonder if my understanding of gtest is incorrect. Perhaps it is designed
to be bundled?

[0]
https://packages.debian.org/sid/devel/capnproto

Re: [PATCH] gnu: Add capnproto.

[Leo Famulari]

On Fri, Aug 19, 2016 at 06:06:24PM -0400, Leo Famulari wrote:
> On Sun, Aug 14, 2016 at 07:16:22PM +0100, Marius Bakke wrote:
> > Leo Famulari <leo@famulari.name> writes:
> > 
> > > On Sat, Aug 13, 2016 at 07:48:36PM +0100, Marius Bakke wrote:
> > >> Note that it bundles googletest; I tried unbundling but it proved
> > >> difficult. gtest will no longer be used from the 0.6 release so I did
> > >> not think a comment was necessary.
> > >
> > > I am cc-ing Lukas with my reply, since he added our googletest package.
> > > Maybe he has some insight.
> > The problem is that their autotools system expects to build gtest as
> > well, so there are references all over. See:
> > https://github.com/sandstorm-io/capnproto/blob/release-0.5.3/c%2B%2B/Makefile.am
> > and also configure.ac. It would have to be patched out, which seems
> > excessive for a 4MB build dependency.
> 
> In my opinion, it's generally not about the size of the bundled
> dependency. Rather, it's about the opacity of the dependency graph of
> the application that does the bundling. The worst case would be
> something like a bundled OpenSSL, for example.
> 
> In this case, Debian has accepted the bundled gtest [0], which makes me
> wonder if my understanding of gtest is incorrect. Perhaps it is designed
> to be bundled?

In any case, since Debian accepted it, I'm willing to accept it as well,
unless somebody objects.

But the patch has gone stale due to other changes in serialization.scm.
Marius, will you send an updated patch?

Re: [PATCH] gnu: Add capnproto.

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

Leo Famulari <leo@famulari.name> writes:

> On Fri, Aug 19, 2016 at 06:06:24PM -0400, Leo Famulari wrote:
>> On Sun, Aug 14, 2016 at 07:16:22PM +0100, Marius Bakke wrote:
>> > Leo Famulari <leo@famulari.name> writes:
>> > 
>> > > On Sat, Aug 13, 2016 at 07:48:36PM +0100, Marius Bakke wrote:
>> > >> Note that it bundles googletest; I tried unbundling but it proved
>> > >> difficult. gtest will no longer be used from the 0.6 release so I did
>> > >> not think a comment was necessary.
>> > >
>> > > I am cc-ing Lukas with my reply, since he added our googletest package.
>> > > Maybe he has some insight.
>> > The problem is that their autotools system expects to build gtest as
>> > well, so there are references all over. See:
>> > https://github.com/sandstorm-io/capnproto/blob/release-0.5.3/c%2B%2B/Makefile.am
>> > and also configure.ac. It would have to be patched out, which seems
>> > excessive for a 4MB build dependency.
>> 
>> In my opinion, it's generally not about the size of the bundled
>> dependency. Rather, it's about the opacity of the dependency graph of
>> the application that does the bundling. The worst case would be
>> something like a bundled OpenSSL, for example.
>> 
>> In this case, Debian has accepted the bundled gtest [0], which makes me
>> wonder if my understanding of gtest is incorrect. Perhaps it is designed
>> to be bundled?

It comes bundled more often than not, but decoupling generally works out
of the box, as it's just linked to as with any library AFAICT:

https://github.com/google/googletest/blob/master/googletest/docs/Primer.md

If it was any other library, or if it wasn't dropped in current git, I
would have gone through the effort of purging it.

> In any case, since Debian accepted it, I'm willing to accept it as well,
> unless somebody objects.
>
> But the patch has gone stale due to other changes in serialization.scm.
> Marius, will you send an updated patch?

New patch below. Thanks!


[-- Attachment #2: 0001-gnu-Add-capnproto.patch --]
[-- Type: text/x-patch, Size: 2310 bytes --]

From 6e73e7c85a044d1da176534ed8ff046431afe617 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
Date: Fri, 12 Aug 2016 13:42:16 +0100
Subject: [PATCH] gnu: Add capnproto.

* gnu/packages/serialization.scm (capnproto): New variable.
---
 gnu/packages/serialization.scm | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/gnu/packages/serialization.scm b/gnu/packages/serialization.scm
index c3ce5c5..4a3278f 100644
--- a/gnu/packages/serialization.scm
+++ b/gnu/packages/serialization.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2015 Ricardo Wurmus <rekado@elephly.net>
 ;;; Copyright © 2016 Lukas Gradl <lgradl@openmailbox.org>
 ;;; Copyright © 2016 David Craven <david@craven.ch>
+;;; Copyright © 2016 Marius Bakke <mbakke@fastmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -170,3 +171,32 @@ including serialization and deserialization to and from strings.  It can also
 preserve existing comment in unserialization/serialization steps, making
 it a convenient format to store user input files.")
     (license license:expat)))
+
+(define-public capnproto
+  (package
+    (name "capnproto")
+    (version "0.5.3")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append
+                    "https://capnproto.org/capnproto-c++-"
+                    version ".tar.gz"))
+              (sha256
+               (base32
+                "1yvaadhgakskqq5wpv53hd6fc3pp17mrdldw4i5cvgck4iwprcfd"))))
+    (build-system gnu-build-system)
+    (arguments
+     `(#:phases
+       (modify-phases %standard-phases
+         (add-before 'check 'do-not-require-/etc/services
+           (lambda _
+             ;; Workaround for test that tries to resolve port name from
+             ;; /etc/services, which is not present in build environment.
+             (substitute* "src/kj/async-io-test.c++" ((":http") ":80"))
+             #t)))))
+    (home-page "https://capnproto.org")
+    (synopsis "Capability-based RPC and serialization system")
+    (description
+     "Cap'n Proto is a very fast data interchange format and capability-based
+RPC system.  Think JSON, except binary.  Or think Protocol Buffers, except faster.")
+    (license license:expat)))
-- 
2.9.2

Re: [PATCH] gnu: Add capnproto.

[Leo Famulari]

On Sat, Aug 20, 2016 at 01:22:30PM +0100, Marius Bakke wrote:
> Subject: [PATCH] gnu: Add capnproto.
> 
> * gnu/packages/serialization.scm (capnproto): New variable.

Thanks, pushed as 557d3328!

By the way, I noticed some other distros include a man page for
capnproto. Can you look into doing something similar for us?

Re: [PATCH] gnu: Add capnproto.

[Marius Bakke]

Leo Famulari <leo@famulari.name> writes:

> On Sat, Aug 20, 2016 at 01:22:30PM +0100, Marius Bakke wrote:
>> Subject: [PATCH] gnu: Add capnproto.
>> 
>> * gnu/packages/serialization.scm (capnproto): New variable.
>
> Thanks, pushed as 557d3328!

Cheers!

> By the way, I noticed some other distros include a man page for
> capnproto. Can you look into doing something similar for us?

Nice find! I guess we can pull the one from Debian. From capnp.1.xml:

      <para>This manual page was written for the Debian system
        (and may be used by others).</para>

Not sure how to add it though, are there other packages with multiple
sources that can be used as reference?

Also, Gentoo apparently decouples gtest by two `sed` commands and
triggering `autoreconf`. I will try that too.

Thanks!
Marius

Re: [PATCH] gnu: Add capnproto.

[Leo Famulari]

On Tue, Aug 23, 2016 at 07:30:10PM +0100, Marius Bakke wrote:
> Leo Famulari <leo@famulari.name> writes:
> > By the way, I noticed some other distros include a man page for
> > capnproto. Can you look into doing something similar for us?
> 
> Nice find! I guess we can pull the one from Debian. From capnp.1.xml:
> 
>       <para>This manual page was written for the Debian system
>         (and may be used by others).</para>
> 
> Not sure how to add it though, are there other packages with multiple
> sources that can be used as reference?

Yes, check the Git package definition for an example of pulling sources
from multiple locations. The git-manpages are distributed as a separate
tarball, and fetched directly from (native-inputs).

Although, I'm not sure how much I like downloading the man page from
Debian. There's nothing explicitly  wrong with it, but I'd rather not
pepper our package definitions with references to random files scattered
across the internet. Other opinions requested on this subject :)

I had hoped the documentation could be built from the capnproto source
or downloading from the capnproto project.

Maybe capnproto can be convinced to adopt Debian's manpage.

> Also, Gentoo apparently decouples gtest by two `sed` commands and
> triggering `autoreconf`. I will try that too.

Great, I look forward to hearing the results!

Re: [PATCH] gnu: Add capnproto.

[Kenton Varda]

Hi, Cap'n Proto upstream author here. Noticed this thread in a Google
search, thought I'd comment.

To shed some light on the googletest situation:

The googletest maintainers have deemed that googletest should never
ever be system-installed, and have even disabled `make install` in
their build. See:

https://github.com/google/googletest/blob/master/googletest/Makefile.am#L300

I don't really understand what they think they're solving here but it
is what it is and this seems to make it hard to use googletest in a
non-bundled way. It's possible I misunderstood, though.

FWIW, Cap'n Proto only uses googletest to build its tests. It does not
install any artifacts that were influenced by googletest.

In any case, this dependency will be gone once I find time to do the
next release. Sorry for the trouble in the meantime.

-Kenton

PS. regarding the man page, I believe Debian mostly generated this
page from the capnp tool's help text. I'd accept a patch to
c++/src/kj/main.c++ which adds some code to generate man XML format
directly, so that we don't have to maintain the same text in multiple
places.

Re: [PATCH] gnu: Add capnproto.

[Marius Bakke]

Kenton Varda <kenton@sandstorm.io> writes:

> Hi, Cap'n Proto upstream author here. Noticed this thread in a Google
> search, thought I'd comment.
>
> To shed some light on the googletest situation:
>
> The googletest maintainers have deemed that googletest should never
> ever be system-installed, and have even disabled `make install` in
> their build. See:
>
> https://github.com/google/googletest/blob/master/googletest/Makefile.am#L300
>
> I don't really understand what they think they're solving here but it
> is what it is and this seems to make it hard to use googletest in a
> non-bundled way. It's possible I misunderstood, though.

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.

> FWIW, Cap'n Proto only uses googletest to build its tests. It does not
> install any artifacts that were influenced by googletest.
>
> In any case, this dependency will be gone once I find time to do the
> next release. Sorry for the trouble in the meantime.

No worries, can't blame you for bundling something clearly designed to
be bundled. It's usually easier to remove, though ;)

> PS. regarding the man page, I believe Debian mostly generated this
> page from the capnp tool's help text. I'd accept a patch to
> c++/src/kj/main.c++ which adds some code to generate man XML format
> directly, so that we don't have to maintain the same text in multiple
> places.

I'm guessing it's the issue I opened that sent you here :)
My C++ fu is not strong enough to embark on that journey, but maybe if
you mention it in the ticket someone may pick it up.

Thanks for the feedback!

Marius

Re: [PATCH] gnu: Add capnproto.

[Alex Vong]

Hi,

Kenton Varda <kenton@sandstorm.io> writes:

> Hi, Cap'n Proto upstream author here. Noticed this thread in a Google
> search, thought I'd comment.
>
> To shed some light on the googletest situation:
>
> The googletest maintainers have deemed that googletest should never
> ever be system-installed, and have even disabled `make install` in
> their build. See:
>
> https://github.com/google/googletest/blob/master/googletest/Makefile.am#L300
>
> I don't really understand what they think they're solving here but it
> is what it is and this seems to make it hard to use googletest in a
> non-bundled way. It's possible I misunderstood, though.
>
> FWIW, Cap'n Proto only uses googletest to build its tests. It does not
> install any artifacts that were influenced by googletest.
>
> In any case, this dependency will be gone once I find time to do the
> next release. Sorry for the trouble in the meantime.
>
> -Kenton
>
> PS. regarding the man page, I believe Debian mostly generated this
> page from the capnp tool's help text. I'd accept a patch to
> c++/src/kj/main.c++ which adds some code to generate man XML format
> directly, so that we don't have to maintain the same text in multiple
> places.

I want to ask what is meant by man XML format? Do you mean to generate
man page? As far as I know, there are at least 2 ways to generate a man
page. One way is to use help2man, which is probably the Debian's
approach. Another way is to write the man page in pod (perl's plain old
documentation) and use pod2man to translate it into a man page. Would
you accept any of these approaches?

Thanks,
Alex

Re: [PATCH] gnu: Add capnproto.

[Marius Bakke]

Alex Vong <alexvong1995@gmail.com> writes:

>> PS. regarding the man page, I believe Debian mostly generated this
>> page from the capnp tool's help text. I'd accept a patch to
>> c++/src/kj/main.c++ which adds some code to generate man XML format
>> directly, so that we don't have to maintain the same text in multiple
>> places.
>
> I want to ask what is meant by man XML format? Do you mean to generate
> man page? As far as I know, there are at least 2 ways to generate a man
> page. One way is to use help2man, which is probably the Debian's
> approach. Another way is to write the man page in pod (perl's plain old
> documentation) and use pod2man to translate it into a man page. Would
> you accept any of these approaches?

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.

Cheers,
Marius

Re: [PATCH] gnu: Add capnproto.

[Kenton Varda]

On Thu, Aug 25, 2016 at 7:57 AM, Marius Bakke <mbakke@fastmail.com> 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