From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenton Varda Subject: Re: [PATCH] gnu: Add capnproto. Date: Thu, 25 Aug 2016 10:22:01 -0700 Message-ID: References: <87vayo28xn.fsf@ike.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcyMW-0004VV-KK for guix-devel@gnu.org; Thu, 25 Aug 2016 13:22:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bcyMQ-0001u5-SF for guix-devel@gnu.org; Thu, 25 Aug 2016 13:22:43 -0400 Received: from o1.smtp.sandstorm.io ([50.31.58.214]:57089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcyMP-0001tE-Lh for guix-devel@gnu.org; Thu, 25 Aug 2016 13:22:38 -0400 Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) by ismtpd0006p1iad1.sendgrid.net (SG) with ESMTP id MsYUqkCYT8Cl2Iow8vfZnw for ; Thu, 25 Aug 2016 17:22:22.856 +0000 (UTC) Received: by mail-it0-f47.google.com with SMTP id x131so284422423ite.0 for ; Thu, 25 Aug 2016 10:22:22 -0700 (PDT) In-Reply-To: <87vayo28xn.fsf@ike.i-did-not-set--mail-host-address--so-tickle-me> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Marius Bakke , Alex Vong Cc: guix-devel@gnu.org On Thu, Aug 25, 2016 at 7:57 AM, Marius Bakke 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