provide a lib output for boost

Dave Love wrote on 3 Oct 2017 18:34

Recipients:(address . guix-patches@gnu.org)

Message-ID:87d164b36m.fsf@albion.it.manchester.ac.uk

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

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

Toggle diff (38 lines)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

Roel Janssen wrote on 11 Oct 2017 10:39

Recipients:(name . Dave Love)(address . dave.love@manchester.ac.uk)(address . 28690@debbugs.gnu.org)

Message-ID:874lr6w02b.fsf@gnu.org

Dave Love writes:

Toggle quote (58 lines)> 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

Dave Love wrote on 19 Oct 2017 12:57

Recipients:(name . Roel Janssen)(address . roel@gnu.org)(address . 28690@debbugs.gnu.org)

Message-ID:87shefmmm1.fsf@albion.it.manchester.ac.uk

[Sorry, this got buried.]

Roel Janssen <roel@gnu.org> writes:

Toggle quote (3 lines)

> 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.

Toggle quote (3 lines)

> 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.]

Thomas Danckaert wrote on 19 Oct 2017 14:52

Recipients:(name . Dave Love)(address . dave.love@manchester.ac.uk)(address . 28690@debbugs.gnu.org)

Message-ID:cuca80nxptb.fsf@thomasdanckaert.be

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

Toggle quote (5 lines)

> 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

Roel Janssen wrote on 19 Oct 2017 16:19

Recipients:(name . Dave Love)(address . dave.love@manchester.ac.uk)(address . 28690@debbugs.gnu.org)

Message-ID:874lqv9q4g.fsf@gnu.org

Dave Love writes:

Toggle quote (25 lines)> [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

Dave Love wrote on 20 Oct 2017 11:20

Recipients:(name . Thomas Danckaert)(address . post@thomasdanckaert.be)(address . 28690@debbugs.gnu.org)

Message-ID:87tvyukwfp.fsf@albion.it.manchester.ac.uk

Thomas Danckaert <post@thomasdanckaert.be> writes:

Toggle quote (5 lines)

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

Toggle quote (9 lines)

> 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.

Thomas Danckaert wrote on 20 Oct 2017 11:46

Recipients:(address . dave.love@manchester.ac.uk)(address . 28690@debbugs.gnu.org)

Message-ID:20171020.114635.656611467612536342.post@thomasdanckaert.be

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

Toggle quote (14 lines)>> 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

Ludovic Courtès wrote on 20 Oct 2017 14:58

Recipients:(name . Dave Love)(address . dave.love@manchester.ac.uk)

Message-ID:87infauga6.fsf@gnu.org

Hi Dave,

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

Toggle quote (18 lines)> 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’.

Thomas Danckaert wrote on 20 Oct 2017 15:21

Recipients:(address . ludo@gnu.org)

Message-ID:20171020.152141.705942693700447320.post@thomasdanckaert.be

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

Toggle quote (4 lines)

> 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

Dave Love wrote on 20 Oct 2017 17:34

Recipients:(name . Thomas Danckaert)(address . post@thomasdanckaert.be)(address . 28690@debbugs.gnu.org)

Message-ID:871slxltor.fsf@albion.it.manchester.ac.uk

Thomas Danckaert <post@thomasdanckaert.be> writes:

Toggle quote (15 lines)>> 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.

Toggle quote (7 lines)

> 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.

Dave Love wrote on 20 Oct 2017 18:09

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87wp3pkdh8.fsf@albion.it.manchester.ac.uk

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

Toggle quote (20 lines)> 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.

Ludovic Courtès wrote on 20 Oct 2017 18:14

Recipients:(name . Thomas Danckaert)(address . post@thomasdanckaert.be)

Message-ID:87o9p1u78l.fsf@gnu.org

Thomas Danckaert <post@thomasdanckaert.be> skribis:

Toggle quote (14 lines)> 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’.

Ludovic Courtès wrote on 20 Oct 2017 22:14

Recipients:(name . Dave Love)(address . dave.love@manchester.ac.uk)

Message-ID:87h8utd1b1.fsf@gnu.org

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

Toggle quote (30 lines)> 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’.

Dave Love wrote on 22 Oct 2017 18:50

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87zi8ji0sw.fsf@albion.it.manchester.ac.uk

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

Toggle quote (12 lines)>> 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 .

Ludovic Courtès wrote on 22 Oct 2017 21:03

Recipients:(name . Dave Love)(address . dave.love@manchester.ac.uk)

Message-ID:87a80j0zv9.fsf@gnu.org

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

Toggle quote (18 lines)> 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’.

Thomas Danckaert wrote on 24 Oct 2017 15:28

Recipients:(address . ludo@gnu.org)

Message-ID:20171024.152840.126421535486070154.post@thomasdanckaert.be

Toggle quote (8 lines)>> 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

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

Ludovic Courtès wrote on 24 Oct 2017 17:30

Recipients:(name . Thomas Danckaert)(address . post@thomasdanckaert.be)

Message-ID:87inf4pnr3.fsf@gnu.org

Thomas Danckaert <post@thomasdanckaert.be> skribis:

Toggle quote (11 lines)>>> 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.

Toggle quote (22 lines)> 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’.

Toggle quote (5 lines)

> 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.

Toggle quote (2 lines)

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

Awesome, let us know how it goes!

Thanks,

Ludo’.

Ricardo Wurmus wrote on 4 Dec 2017 00:07

Recipients:(name . Thomas Danckaert)(address . post@thomasdanckaert.be)

Message-ID:871skb4di3.fsf@elephly.net

Hi Thomas,

Toggle quote (2 lines)

> 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

Thomas Danckaert wrote on 4 Dec 2017 09:19

Recipients:(address . rekado@elephly.net)

Message-ID:20171204.091953.594379672344347781.post@thomasdanckaert.be

Toggle quote (6 lines)

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

Christopher Baines wrote on 19 Mar 2018 09:02

control message for bug #28690

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87vads5w8i.fsf@cbaines.net

tags 28690 patch

zimoun wrote on 13 Jan 16:45 +0100

Re: bug#28690: provide a lib output for boost

Recipients:(address . 28690@debbugs.gnu.org)

Message-ID:86sftriqr3.fsf@gmail.com

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:

Toggle quote (7 lines)

> 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:

Toggle snippet (15 lines)

$ 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

Note that that’s a core-updates change.

Toggle snippet (5 lines)

$ guix refresh -l boost | cut -f1 -d':'

Building the following 4921 packages would ensure 7338 dependent packages are rebuilt

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

Toggle quote (16 lines)>>> 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

zimoun wrote on 3 Feb 03:30 +0100

Recipients:(address . 28690@debbugs.gnu.org)

Message-ID:86mtj81y3b.fsf_-_@gmail.com

Hi,

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

Toggle quote (11 lines)> 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:

[...]

Toggle quote (4 lines)

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

> Now, the size is:

[...]

Toggle quote (11 lines)

> 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

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date