From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5AJv-0003AH-9K for guix-patches@gnu.org; Thu, 19 Oct 2017 08:53:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5AJq-0003E6-D8 for guix-patches@gnu.org; Thu, 19 Oct 2017 08:53:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:40580) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e5AJq-0003Dx-9T for guix-patches@gnu.org; Thu, 19 Oct 2017 08:53:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e5AJq-0006AZ-26 for guix-patches@gnu.org; Thu, 19 Oct 2017 08:53:02 -0400 Subject: [bug#28690] provide a lib output for boost Resent-Message-ID: From: Thomas Danckaert References: <87d164b36m.fsf@albion.it.manchester.ac.uk> Date: Thu, 19 Oct 2017 14:52:32 +0200 In-Reply-To: <87d164b36m.fsf@albion.it.manchester.ac.uk> (Dave Love's message of "Tue, 03 Oct 2017 17:34:41 +0100") Message-ID: 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: > I mentioned elsewhere noticing the large size of boost in closures. > I've now realized what the problem was with making a lib output, and > done one, as below. However, presumably it should have a dependency of > out on lib for compatibility, and I don't know the right way to do that. Yes, I've also noticed that, and also think it's worth to split the package. I don't think it's possible to have one output of a package depend on another, though. We could just add boost:lib to the inputs for every package which relies on boost (except for packages which only rely on header-only parts of boost)? Another solution might be to turn the 2 outputs into 2 separate guix packages, "boost" and "boost-libs", where "boost" only contains the headers, and has "boost-libs" as a propagated-input. I'm not sure if this will do the right thing (i.e. make boost-libs available in the build environment when boost is a regular input, but not propagate it further), someone should try it out ;). Thomas