From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5Bh4-0007bi-Ka for guix-patches@gnu.org; Thu, 19 Oct 2017 10:21:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5Bh0-0001HO-QD for guix-patches@gnu.org; Thu, 19 Oct 2017 10:21:06 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:41808) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e5Bh0-0001HH-MM for guix-patches@gnu.org; Thu, 19 Oct 2017 10:21:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e5Bh0-0000Gc-Fe for guix-patches@gnu.org; Thu, 19 Oct 2017 10:21:02 -0400 Subject: [bug#28690] provide a lib output for boost Resent-Message-ID: References: <87d164b36m.fsf@albion.it.manchester.ac.uk> <874lr6w02b.fsf@gnu.org> <87shefmmm1.fsf@albion.it.manchester.ac.uk> From: Roel Janssen In-reply-to: <87shefmmm1.fsf@albion.it.manchester.ac.uk> Date: Thu, 19 Oct 2017 16:19:43 +0200 Message-ID: <874lqv9q4g.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Dave Love Cc: 28690@debbugs.gnu.org Dave Love writes: > [Sorry, this got buried.] > > Roel Janssen writes: > >> Boost consists of various modules or components. Some of these are >> "header-only". How does this patch handle that? > > The headers are in the main package, compatibly with the current > situation if you're not doing anything which depends on the runtime. > >> If I were to install the "lib" output, could I then compile a C++ >> program that uses a header-only part of Boost? > > No. The point of the patch is not to pay the price of the headers in > space at run time. > > I think you should be able to use just "boost" as an input, and build > things which require the runtime (certainly for compatibility), hence my > question about the right way to make the dependency. > > [I'm not convinced by Guix' convention for packaging compared with > having the development sub-packages of other distributions, at least if > you're trying to stop the closure of one package being comparable with > the size I expect of an entire HPC node image.] Ah, now I understand. We could indeed reduce the size of the closure by having a small boost package that contains all the run-time references needed by programs. Thanks! Kind regards, Roel Janssen