[bug#28690] provide a lib output for boost

[bug#28690] provide a lib output for boost

[Dave Love]

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

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.

The lib package is 17MiB, and the headers are 108MiB.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-gnu-boost-Make-a-lib-output.patch --]
[-- Type: text/x-diff, Size: 1928 bytes --]

From 1bb845d1d45ee7e8b9447bab902f3de41f0acfac Mon Sep 17 00:00:00 2001
From: Dave Love <fx@gnu.org>
Date: Tue, 3 Oct 2017 16:18:59 +0100
Subject: [PATCH] gnu: boost: Make a "lib" output.

This save about half the contribution to the Closure of things linked against
it,

* gnu/packages/boost.scm(outputs): Add lib.
(arguments)[mv-lib]: Add move the lib output into place after install.
---
 gnu/packages/boost.scm | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
index 4c7308e9d..c1e622fcd 100644
--- a/gnu/packages/boost.scm
+++ b/gnu/packages/boost.scm
@@ -53,6 +53,7 @@
      `(("perl" ,perl)
        ("python" ,python-2)
        ("tcsh" ,tcsh)))
+    (outputs '("out" "lib"))
     (arguments
      `(#:tests? #f
        #:make-flags
@@ -60,7 +61,7 @@
 
              ;; Set the RUNPATH to $libdir so that the libs find each other.
              (string-append "linkflags=-Wl,-rpath="
-                            (assoc-ref %outputs "out") "/lib")
+                            (assoc-ref %outputs "lib") "/lib")
 
              ;; Boost's 'context' library is not yet supported on mips64, so
              ;; we disable it.  The 'coroutine' library depends on 'context',
@@ -99,7 +100,13 @@
          (replace
              'install
            (lambda* (#:key outputs make-flags #:allow-other-keys)
-             (zero? (apply system* "./b2" "install" make-flags)))))))
+             (zero? (apply system* "./b2" "install" make-flags))))
+         (add-after 'install 'mv-lib
+           (lambda _
+             (mkdir-p (assoc-ref %outputs "lib"))
+             (rename-file (string-append %output "/lib")
+                          (string-append (assoc-ref %outputs "lib")
+                                         "/lib")))))))
 
     (home-page "http://boost.org")
     (synopsis "Peer-reviewed portable C++ source libraries")
-- 
2.11.0

[bug#28690] provide a lib output for boost

[Roel Janssen]

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.
>
> The lib package is 17MiB, and the headers are 108MiB.
>
>>From 1bb845d1d45ee7e8b9447bab902f3de41f0acfac Mon Sep 17 00:00:00 2001
> From: Dave Love <fx@gnu.org>
> Date: Tue, 3 Oct 2017 16:18:59 +0100
> Subject: [PATCH] gnu: boost: Make a "lib" output.
>
> This save about half the contribution to the Closure of things linked against
> it,
>
> * gnu/packages/boost.scm(outputs): Add lib.
> (arguments)[mv-lib]: Add move the lib output into place after install.
> ---
>  gnu/packages/boost.scm | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/boost.scm b/gnu/packages/boost.scm
> index 4c7308e9d..c1e622fcd 100644
> --- a/gnu/packages/boost.scm
> +++ b/gnu/packages/boost.scm
> @@ -53,6 +53,7 @@
>       `(("perl" ,perl)
>         ("python" ,python-2)
>         ("tcsh" ,tcsh)))
> +    (outputs '("out" "lib"))
>      (arguments
>       `(#:tests? #f
>         #:make-flags
> @@ -60,7 +61,7 @@
>  
>               ;; Set the RUNPATH to $libdir so that the libs find each other.
>               (string-append "linkflags=-Wl,-rpath="
> -                            (assoc-ref %outputs "out") "/lib")
> +                            (assoc-ref %outputs "lib") "/lib")
>  
>               ;; Boost's 'context' library is not yet supported on mips64, so
>               ;; we disable it.  The 'coroutine' library depends on 'context',
> @@ -99,7 +100,13 @@
>           (replace
>               'install
>             (lambda* (#:key outputs make-flags #:allow-other-keys)
> -             (zero? (apply system* "./b2" "install" make-flags)))))))
> +             (zero? (apply system* "./b2" "install" make-flags))))
> +         (add-after 'install 'mv-lib
> +           (lambda _
> +             (mkdir-p (assoc-ref %outputs "lib"))
> +             (rename-file (string-append %output "/lib")
> +                          (string-append (assoc-ref %outputs "lib")
> +                                         "/lib")))))))
>  
>      (home-page "http://boost.org")
>      (synopsis "Peer-reviewed portable C++ source libraries")

Boost consists of various modules or components.  Some of these are
"header-only".  How does this patch handle that?

If I were to install the "lib" output, could I then compile a C++
program that uses a header-only part of Boost?

Kind regards,
Roel Janssen

[bug#28690] provide a lib output for boost

[Dave Love]

[Sorry, this got buried.]

Roel Janssen <roel@gnu.org> 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.]

[bug#28690] provide a lib output for boost

[Thomas Danckaert]

Dave Love <dave.love@manchester.ac.uk> 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

[bug#28690] provide a lib output for boost

[Roel Janssen]

Dave Love writes:

> [Sorry, this got buried.]
>
> Roel Janssen <roel@gnu.org> 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

[bug#28690] provide a lib output for boost

[Dave Love]

Thomas Danckaert <post@thomasdanckaert.be> writes:

> 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)?

Sorry, I don't understand; the usual problem seems to be _preventing_
that, e.g. to cure cycles.  It may not be in the package definition, but
if I mention "lib" in some file in "out", it will do the job, won't it?

> 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

I don't think that's necessary, but the fact that this sort of thing
isn't straightforward seems to me a Guix deficiency which might be
addressed.

[bug#28690] provide a lib output for boost

[Thomas Danckaert]

From: Dave Love <dave.love@manchester.ac.uk>
Subject: Re: [bug#28690] provide a lib output for boost
Date: Fri, 20 Oct 2017 10:20:10 +0100

>> 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)?
>
> Sorry, I don't understand; the usual problem seems to be 
> _preventing_
> that, e.g. to cure cycles.  It may not be in the package 
> definition, but
> if I mention "lib" in some file in "out", it will do the job, won't 
> it?

This is enough to retain a store reference to the "lib" output (so 
lib becomes part of the package closure), but I don't think this is 
enough to make the “boost:lib” output available in the build 
environment of a package which only explicitly relies on “boost:out”. 
 I mean that a package which needs to link against boost:lib will not 
find it in the build phase, unless boost:lib is explicitly added to 
its inputs (or propagated by boost:out, see my other suggestion).

But I'm largely speculating here, haven't tried any of this out...  
Not sure what the “deficiency” is (provided one of these solutions 
works, maybe they'd both work).  Probably “propagated-inputs”, 
“native-inputs” and normal “inputs” should be explained more 
thoroughly in the manual, perhaps with 1 or 2 examples (As you see, 
I'm not 100% sure how it all fits together, or I'd write it myself.  
Maybe I should just submit a patch for the manual and see what 
comments I get.).

Other than that, having a separate “boost headers” and “boost so's” 
output doesn't sound so bad to me (and isn't it quite common for 
other distributions to have separate packages boost and boost-dev, 
where only boost-dev would include the headers?).

Thomas

[bug#28690] provide a lib output for boost

[Ludovic Courtès]

Hi Dave,

Dave Love <dave.love@manchester.ac.uk> skribis:

> Roel Janssen <roel@gnu.org> 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.

The choice was made to allow package definitions to explicitly state
which outputs of their dependencies they’re interested in.  So it you
have

  `("boost" ,boost)

that’s only boost:out; if you have:

  `("boost" ,boost "lib")

that’s only boost:lib.  If you want both, you need to specify both.

So far I don’t think this was considered a problem; on the contrary, you
could get fine-grain control, as in glib:out vs. glib:bin.  In this
particular case, I agree that it’s annoying to have to specify both.

If this “particular case” happens to be common enough, we can always
revisit the above decision and chance `("boost" ,boost) to mean “all the
outputs of boost.”

At any rate, the patch LGTM in principle.  It’ll have to go to
‘core-updates’ though.

Thomas, Roel: are you taking care of it?  :-)

Thanks,
Ludo’.

[bug#28690] provide a lib output for boost

[Thomas Danckaert]

From: ludo@gnu.org (Ludovic Courtès)
Subject: Re: [bug#28690] provide a lib output for boost
Date: Fri, 20 Oct 2017 14:58:57 +0200

> At any rate, the patch LGTM in principle.  It’ll have to go to
> ‘core-updates’ though.
>
> Thomas, Roel: are you taking care of it?  :-)

I'm happy to push this to core-updates.  What do we do with packages 
requiring boost:lib?   Do we just wait and see which builds fail on 
core-updates, and add `("boost" ,boost "lib") as an input where 
required?

Thomas

[bug#28690] provide a lib output for boost

[Dave Love]

Thomas Danckaert <post@thomasdanckaert.be> writes:

>> Sorry, I don't understand; the usual problem seems to be
>> _preventing_
>> that, e.g. to cure cycles.  It may not be in the package definition,
>> but
>> if I mention "lib" in some file in "out", it will do the job, won't
>> it?
>
> This is enough to retain a store reference to the "lib" output (so lib
> becomes part of the package closure), but I don't think this is enough
> to make the “boost:lib” output available in the build environment of a
> package which only explicitly relies on “boost:out”. I mean that a
> package which needs to link against boost:lib will not find it in the
> build phase, unless boost:lib is explicitly added to its inputs (or
> propagated by boost:out, see my other suggestion).

Sorry, yes.  I've fallen for that before, now I think of it.

> But I'm largely speculating here, haven't tried any of this out...
> Not sure what the “deficiency” is (provided one of these solutions
> works, maybe they'd both work).  Probably “propagated-inputs”,
> “native-inputs” and normal “inputs” should be explained more
> thoroughly in the manual, perhaps with 1 or 2 examples (As you see,
> I'm not 100% sure how it all fits together, or I'd write it myself.

That's two of us.  I've intended to write something for "conversion"
from other packaging systems, but definitely don't understand enough
yet.

[bug#28690] provide a lib output for boost

[Dave Love]

Ludovic Courtès <ludo@gnu.org> writes:

> The choice was made to allow package definitions to explicitly state
> which outputs of their dependencies they’re interested in.  So it you
> have
>
>   `("boost" ,boost)
>
> that’s only boost:out; if you have:
>
>   `("boost" ,boost "lib")
>
> that’s only boost:lib.  If you want both, you need to specify both.
>
> So far I don’t think this was considered a problem; on the contrary, you
> could get fine-grain control, as in glib:out vs. glib:bin.  In this
> particular case, I agree that it’s annoying to have to specify both.
>
> If this “particular case” happens to be common enough, we can always
> revisit the above decision and chance `("boost" ,boost) to mean “all the
> outputs of boost.”

It looks to me that it will be common if you want to reduce closures.
Also, in other distributions you know that you can build-depend on the
-dev(el) package and get what you need without having to know about
various sub-packages (outputs), and the runtime requirements should be
minimal (although there are sometimes problems with unnecessary
dependencies).  As far as I know, Guix doesn't have an easy way to find
what provides particular files to determine the inputs.

I don't think these things are fundamental, obviously, and I may just be
too set in my ways from other systems.  It's all meant as constructive
criticism, of course.

[bug#28690] provide a lib output for boost

[Ludovic Courtès]

Thomas Danckaert <post@thomasdanckaert.be> skribis:

> From: ludo@gnu.org (Ludovic Courtès)
> Subject: Re: [bug#28690] provide a lib output for boost
> Date: Fri, 20 Oct 2017 14:58:57 +0200
>
>> At any rate, the patch LGTM in principle.  It’ll have to go to
>> ‘core-updates’ though.
>>
>> Thomas, Roel: are you taking care of it?  :-)
>
> I'm happy to push this to core-updates.  What do we do with packages
> requiring boost:lib?   Do we just wait and see which builds fail on
> core-updates, and add `("boost" ,boost "lib") as an input where
> required?

It would be ideal to identify them by building (some of) Boost’s direct
dependencies.  This can be done on master to avoid rebuilding the world,
and then pushed to core-updates.

Thanks,
Ludo’.

[bug#28690] provide a lib output for boost

[Ludovic Courtès]

Dave Love <dave.love@manchester.ac.uk> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> The choice was made to allow package definitions to explicitly state
>> which outputs of their dependencies they’re interested in.  So it you
>> have
>>
>>   `("boost" ,boost)
>>
>> that’s only boost:out; if you have:
>>
>>   `("boost" ,boost "lib")
>>
>> that’s only boost:lib.  If you want both, you need to specify both.
>>
>> So far I don’t think this was considered a problem; on the contrary, you
>> could get fine-grain control, as in glib:out vs. glib:bin.  In this
>> particular case, I agree that it’s annoying to have to specify both.
>>
>> If this “particular case” happens to be common enough, we can always
>> revisit the above decision and chance `("boost" ,boost) to mean “all the
>> outputs of boost.”
>
> It looks to me that it will be common if you want to reduce closures.
> Also, in other distributions you know that you can build-depend on the
> -dev(el) package and get what you need without having to know about
> various sub-packages (outputs), and the runtime requirements should be
> minimal (although there are sometimes problems with unnecessary
> dependencies).  As far as I know, Guix doesn't have an easy way to find
> what provides particular files to determine the inputs.

Yeah, you may be right.  Nixpkgs took that route when they introduced
multiple outputs not long ago.

Well, something to experiment with I guess!

Thanks,
Ludo’.

[bug#28690] provide a lib output for boost

[Dave Love]

Ludovic Courtès <ludo@gnu.org> writes:

>> I'm happy to push this to core-updates.  What do we do with packages
>> requiring boost:lib?   Do we just wait and see which builds fail on
>> core-updates, and add `("boost" ,boost "lib") as an input where
>> required?
>
> It would be ideal to identify them by building (some of) Boost’s direct
> dependencies.  This can be done on master to avoid rebuilding the world,
> and then pushed to core-updates.
>
> Thanks,
> Ludo’.

I don't know if it helps, or is well-known anyhow, but you can check the
dependencies of any that are in Debian by looking under
https://packages.debian.org/sid/<package>.

[bug#28690] provide a lib output for boost

[Ludovic Courtès]

Dave Love <dave.love@manchester.ac.uk> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> I'm happy to push this to core-updates.  What do we do with packages
>>> requiring boost:lib?   Do we just wait and see which builds fail on
>>> core-updates, and add `("boost" ,boost "lib") as an input where
>>> required?
>>
>> It would be ideal to identify them by building (some of) Boost’s direct
>> dependencies.  This can be done on master to avoid rebuilding the world,
>> and then pushed to core-updates.
>>
>> Thanks,
>> Ludo’.
>
> I don't know if it helps, or is well-known anyhow, but you can check the
> dependencies of any that are in Debian by looking under
> https://packages.debian.org/sid/<package>.

I don’t think it helps.  I suggest looking for the direct dependencies
of Boost in Guix, possibly using ‘guix refresh -l boost’.

Ludo’.

[bug#28690] provide a lib output for boost

[Thomas Danckaert]

[-- Attachment #1: Type: Text/Plain, Size: 1450 bytes --]

>> I don't know if it helps, or is well-known anyhow, but you can 
>> check the
>> dependencies of any that are in Debian by looking under
>> https://packages.debian.org/sid/<package>.
>
> I don’t think it helps.  I suggest looking for the direct 
> dependencies
> of Boost in Guix, possibly using ‘guix refresh -l boost’.

Doesn't that also lists indirect dependencies (575 of them)?  After 
some experimentation at the REPL, I came up with the following to 
find only packages directly depending on boost:

(use-modules
  (srfi srfi-1)
  (guix packages)
  (gnu packages)
  (gnu packages boost)
  (guix scripts refresh))

(define (depends-on-boost pkg)
   (any (lambda (p) (eq? p boost))
        (map cadr (append (package-inputs pkg)
                          (package-propagated-inputs pkg)
                          (package-native-inputs pkg)))))

(let ((all-deps (filter depends-on-boost (fold-packages cons '()))))
   (format (current-output-port)
           "~{~a~^~%~}~%" (map package-name all-deps)))

Leading to the 97 dependencies in the attached file.

Is that approach correct?  There are also 3 packages which have boost 
as a propagated input (mdds, gpgmepp and librevenge).  That could 
lead to further packages depending on boost, which are missing from 
the list, but for now I'll assume that such cases are rare.

Meanwhile I'll try to build those 97 packages, stay tuned ;-)

Thomas

[-- Attachment #2: boostdeps.txt --]
[-- Type: Text/Plain, Size: 861 bytes --]

abiword
synfig
patchage
guitarix-lv2
raul
ardour
csound
lvtk
raul
guitarix
imp
seek
ritornello
metabat
bless
express
cufflinks
tophat
rsem
r-mzr
discrover
libtorrent-rasterbar
mdds
mysql
linuxdcpp
pulseview
fritzing
librecad
ao-cad
volk
kicad
monero-core
ledger
bitcoin-core
monero
exempi
openmw
grfcodec
mygui
mupen64plus-video-glide64mk2
wesnoth
pingus
lierolibre
supertux
emulation-station
0ad
ogre
cgal
openimageio
blender
mia
luminance-hdr
vigra
gpick
inkscape
kactivities
kactivities-stats
gpgmepp
kdevplatform
libetonyek
librevenge
libwps
libmwaw
libcdr
libcmis
libzmf
libodfgen
libreoffice
libmspub
libvisio
libpagemaker
libabw
libe-book
randomjungle
dealii-openmpi
dealii
chromaprint
mpd
ncmpcpp
klick
ingen
yoshimi
powertabeditor
coq-gappa
hugin
enblend-enfuse
source-highlight
highlight
clucene
sdcc
yaml-cpp
mosh
ceph
swig
mumble
kakoune
mkvtoolnix

[bug#28690] provide a lib output for boost

[Ludovic Courtès]

Thomas Danckaert <post@thomasdanckaert.be> skribis:

>>> I don't know if it helps, or is well-known anyhow, but you can
>>> check the
>>> dependencies of any that are in Debian by looking under
>>> https://packages.debian.org/sid/<package>.
>>
>> I don’t think it helps.  I suggest looking for the direct
>> dependencies
>> of Boost in Guix, possibly using ‘guix refresh -l boost’.
>
> Doesn't that also lists indirect dependencies (575 of them)? 

Yes it does.

> After some experimentation at the REPL, I came up with the following
> to find only packages directly depending on boost:
>
> (use-modules
>  (srfi srfi-1)
>  (guix packages)
>  (gnu packages)
>  (gnu packages boost)
>  (guix scripts refresh))
>
> (define (depends-on-boost pkg)
>   (any (lambda (p) (eq? p boost))
>        (map cadr (append (package-inputs pkg)
>                          (package-propagated-inputs pkg)
>                          (package-native-inputs pkg)))))
>
> (let ((all-deps (filter depends-on-boost (fold-packages cons '()))))
>   (format (current-output-port)
>           "~{~a~^~%~}~%" (map package-name all-deps)))
>
> Leading to the 97 dependencies in the attached file.

Neat!  We should add something like this to ‘guix refresh’.

> Is that approach correct?  There are also 3 packages which have boost
> as a propagated input (mdds, gpgmepp and librevenge).  That could lead
> to further packages depending on boost, which are missing from the
> list, but for now I'll assume that such cases are rare.

The approach looks correct, yes.

> Meanwhile I'll try to build those 97 packages, stay tuned ;-)

Awesome, let us know how it goes!

Thanks,
Ludo’.

[bug#28690] provide a lib output for boost

[Ricardo Wurmus]

Hi Thomas,

> Meanwhile I'll try to build those 97 packages, stay tuned ;-)

have you been able to build some of these packages to verify that this
patch is fine?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

[bug#28690] provide a lib output for boost

[Thomas Danckaert]

From: Ricardo Wurmus <rekado@elephly.net>
Subject: Re: [bug#28690] provide a lib output for boost
Date: Mon, 04 Dec 2017 00:07:16 +0100

>> Meanwhile I'll try to build those 97 packages, stay tuned ;-)
>
> have you been able to build some of these packages to verify that 
> this
> patch is fine?

I tried to build them all, but only a few packages built successfully 
(those).  Most packages probably just need boost:lib added to their 
inputs (I already fixed a few in my local tree), but sometimes the 
build fails for other reasons, and verifying them all takes time (the 
list includes things like vigra and libreoffice).

I should have some time in the holiday period, but help is welcome :)

The updated list and a few patches are on my other computer, I'll 
post them when I get home.

Thomas

[bug#28690] provide a lib output for boost

[zimoun]

Hi,

This patch #28690 [1] is about adding an output to boost.  The aim is to
reduce the closure size.

The last message if from Dec. 2017 and indicates some issues.


1: <http://issues.guix.gnu.org/issue/28690>


On Tue, 03 Oct 2017 at 17:34, Dave Love <dave.love@manchester.ac.uk> wrote:

> 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.
>
> The lib package is 17MiB, and the headers are 108MiB.

Now, the size is:

--8<---------------cut here---------------start------------->8---
$ guix size boost
store item                                  total    self
/gnu/store/rwv6khi7hg3hrhij9kimxh53mvg8ksd9-boost-1.77.0           262.0   149.7  57.1%
/gnu/store/7sik9fp2ffvnr7l01s423x4r5pn75rf9-icu4c-69.1             110.7    38.0  14.5%
/gnu/store/2fk1gz2s7ppdicynscra9b19byrrr866-glibc-2.33              38.3    36.6  14.0%
/gnu/store/90lbavffg0csrf208nw0ayj1bz5knl47-gcc-10.3.0-lib          71.7    33.4  12.7%
/gnu/store/ggrih6fgnflxs6k87m8q2l9ky0za8y1z-bash-static-5.1.8        1.7     1.7   0.6%
/gnu/store/72kpdqplq4nc87fm7ch47kxy3nlkzsyx-xz-5.2.5                73.7     1.1   0.4%
/gnu/store/vx6vfbmmazvfi7vp8xyjn2mcyylvw9gn-bash-minimal-5.1.8      39.3     1.0   0.4%
/gnu/store/w6zv2mz56wyxr471q38a3cmzm4iqimy8-bzip2-1.0.8             73.1     0.4   0.2%
/gnu/store/2i0zpa5w320y8m4zbqk1va8vs6dbawv0-zlib-1.2.11             71.9     0.2   0.1%
total: 262.0 MiB
--8<---------------cut here---------------end--------------->8---


Note that that’s a core-updates change.

--8<---------------cut here---------------start------------->8---
$ guix refresh -l boost | cut -f1 -d':'
Building the following 4921 packages would ensure 7338 dependent packages are rebuilt
--8<---------------cut here---------------end--------------->8---


On Mon, 04 Dec 2017 at 09:19, Thomas Danckaert <post@thomasdanckaert.be> wrote:

>>> Meanwhile I'll try to build those 97 packages, stay tuned ;-)
>>
>> have you been able to build some of these packages to verify that this
>> patch is fine?
>
> I tried to build them all, but only a few packages built successfully (those).
> Most packages probably just need boost:lib added to their inputs (I already
> fixed a few in my local tree), but sometimes the build fails for other
> reasons, and verifying them all takes time (the list includes things like
> vigra and libreoffice).
>
> I should have some time in the holiday period, but help is welcome :)
>
> The updated list and a few patches are on my other computer, I'll post them
> when I get home.

Therefore, if I understand correctly, some work remains.  The question
is: is it worth to complete such work about adding more outputs to
boost?

WDYT?


Cheers,
simon

[bug#28690] provide a lib output for boost

[zimoun]

Hi,

On Thu, 13 Jan 2022 at 16:45, zimoun <zimon.toutoune@gmail.com> wrote:

> This patch #28690 [1] is about adding an output to boost.  The aim is to
> reduce the closure size.
>
> The last message if from Dec. 2017 and indicates some issues.
>
>
> 1: <http://issues.guix.gnu.org/issue/28690>
>
>
> On Tue, 03 Oct 2017 at 17:34, Dave Love <dave.love@manchester.ac.uk> wrote:

[...]

>> The lib package is 17MiB, and the headers are 108MiB.
>
> Now, the size is:

[...]

> total: 262.0 MiB

> On Mon, 04 Dec 2017 at 09:19, Thomas Danckaert <post@thomasdanckaert.be> wrote:

>> The updated list and a few patches are on my other computer, I'll post them
>> when I get home.
>
> Therefore, if I understand correctly, some work remains.  The question
> is: is it worth to complete such work about adding more outputs to
> boost?

Since some work remains and it is not clear if it is worth to complete
such work about adding more outputs to boost, I plan to mark this report
as ’donewontfix’.  Let me know if it is worth to keep it open.


Cheers,
simon

[bug#28690] provide a lib output for boost

[zimoun]

Hi,

On Thu, 03 Feb 2022 at 03:30, zimoun <zimon.toutoune@gmail.com> wrote:
> On Thu, 13 Jan 2022 at 16:45, zimoun <zimon.toutoune@gmail.com> wrote:
>> On Tue, 03 Oct 2017 at 17:34, Dave Love <dave.love@manchester.ac.uk> wrote:
>> On Mon, 04 Dec 2017 at 09:19, Thomas Danckaert <post@thomasdanckaert.be> wrote:

>> This patch #28690 [1] is about adding an output to boost.  The aim is to
>> reduce the closure size.
>>
>> The last message if from Dec. 2017 and indicates some issues.
>>
>>
>> 1: <http://issues.guix.gnu.org/issue/28690>

[...]

> Since some work remains and it is not clear if it is worth to complete
> such work about adding more outputs to boost, I plan to mark this report
> as ’donewontfix’.  Let me know if it is worth to keep it open.

Any objection closing?  If not, I will close it in 2 weeks.


Cheers,
simon

[bug#28690] provide a lib output for boost

[Thomas Danckaert via Guix-patches]

On 2022-06-23 12:01, zimoun wrote:
> Hi,
> 
> On Thu, 03 Feb 2022 at 03:30, zimoun <zimon.toutoune@gmail.com> wrote:
>> On Thu, 13 Jan 2022 at 16:45, zimoun <zimon.toutoune@gmail.com> wrote:
>>> On Tue, 03 Oct 2017 at 17:34, Dave Love <dave.love@manchester.ac.uk> 
>>> wrote:
>>> On Mon, 04 Dec 2017 at 09:19, Thomas Danckaert 
>>> <post@thomasdanckaert.be> wrote:
> 
>>> This patch #28690 [1] is about adding an output to boost.  The aim is 
>>> to
>>> reduce the closure size.
>>> 
>>> The last message if from Dec. 2017 and indicates some issues.
>>> 
>>> 
>>> 1: <http://issues.guix.gnu.org/issue/28690>
> 
> [...]
> 
>> Since some work remains and it is not clear if it is worth to complete
>> such work about adding more outputs to boost, I plan to mark this 
>> report
>> as ’donewontfix’.  Let me know if it is worth to keep it open.
> 
> Any objection closing?  If not, I will close it in 2 weeks.

I'm no longer a very active contributor (or user :/), so not sure I'm 
the right person to judge this.  Reducing boost package size is a nice 
thing to do, but I'm not going to do the necessary work of building all 
(or at least a significant subset of) boost reverse dependencies to 
check if the approach above works, or if more changes are necessary.

I guess someone can always pick up the patch again when they feel the 
need for a smaller boost package.

Thomas

bug#28690: provide a lib output for boost

[zimoun]

Hi,

On Thu, 23 Jun 2022 at 13:35, post@thomasdanckaert.be wrote:
> On 2022-06-23 12:01, zimoun wrote:
>> On Thu, 03 Feb 2022 at 03:30, zimoun <zimon.toutoune@gmail.com> wrote:
>>> On Thu, 13 Jan 2022 at 16:45, zimoun <zimon.toutoune@gmail.com> wrote:

>>>> This patch #28690 [1] is about adding an output to boost.  The aim is to
>>>> reduce the closure size.
>>>> The last message if from Dec. 2017 and indicates some issues.
>>>>
>>>> 1: <http://issues.guix.gnu.org/issue/28690>

>>> Since some work remains and it is not clear if it is worth to complete
>>> such work about adding more outputs to boost, I plan to mark this report
>>> as ’donewontfix’.  Let me know if it is worth to keep it open.

>> Any objection closing?  If not, I will close it in 2 weeks.

> I'm no longer a very active contributor (or user :/), so not sure I'm the
> right person to judge this.  Reducing boost package size is a nice thing to
> do, but I'm not going to do the necessary work of building all (or at least a
> significant subset of) boost reverse dependencies to check if the approach
> above works, or if more changes are necessary.

I agree that the closure of boost deserve more love.

> I guess someone can always pick up the patch again when they feel the need for
> a smaller boost package.

Well, I am in favor to close it because it requires some work for
rebasing, etc. and the pending patches are such large that I am doubtful
people wanting to work on reducing the closure of boost will start to
look here. :-)


Cheers,
simon