provide a lib output for boost

  • Done
  • quality assurance status badge
Details
7 participants
  • Dave Love
  • Ludovic Courtès
  • Christopher Baines
  • Thomas Danckaert
  • Ricardo Wurmus
  • Roel Janssen
  • zimoun
Owner
unassigned
Submitted by
Dave Love
Severity
normal
D
D
Dave Love wrote on 3 Oct 2017 18:34
(address . guix-patches@gnu.org)
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
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(-)

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
R
R
Roel Janssen wrote on 11 Oct 2017 10:39
(name . Dave Love)(address . dave.love@manchester.ac.uk)(address . 28690@debbugs.gnu.org)
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
D
D
Dave Love wrote on 19 Oct 2017 12:57
(name . Roel Janssen)(address . roel@gnu.org)(address . 28690@debbugs.gnu.org)
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.]
T
T
Thomas Danckaert wrote on 19 Oct 2017 14:52
(name . Dave Love)(address . dave.love@manchester.ac.uk)(address . 28690@debbugs.gnu.org)
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
R
R
Roel Janssen wrote on 19 Oct 2017 16:19
(name . Dave Love)(address . dave.love@manchester.ac.uk)(address . 28690@debbugs.gnu.org)
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
D
D
Dave Love wrote on 20 Oct 2017 11:20
(name . Thomas Danckaert)(address . post@thomasdanckaert.be)(address . 28690@debbugs.gnu.org)
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.
T
T
Thomas Danckaert wrote on 20 Oct 2017 11:46
(address . dave.love@manchester.ac.uk)(address . 28690@debbugs.gnu.org)
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
L
L
Ludovic Courtès wrote on 20 Oct 2017 14:58
(name . Dave Love)(address . dave.love@manchester.ac.uk)
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’.
T
T
Thomas Danckaert wrote on 20 Oct 2017 15:21
(address . ludo@gnu.org)
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
D
D
Dave Love wrote on 20 Oct 2017 17:34
(name . Thomas Danckaert)(address . post@thomasdanckaert.be)(address . 28690@debbugs.gnu.org)
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.
D
D
Dave Love wrote on 20 Oct 2017 18:09
(name . Ludovic Courtès)(address . ludo@gnu.org)
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.
L
L
Ludovic Courtès wrote on 20 Oct 2017 18:14
(name . Thomas Danckaert)(address . post@thomasdanckaert.be)
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’.
L
L
Ludovic Courtès wrote on 20 Oct 2017 22:14
(name . Dave Love)(address . dave.love@manchester.ac.uk)
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’.
D
D
Dave Love wrote on 22 Oct 2017 18:50
(name . Ludovic Courtès)(address . ludo@gnu.org)
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
L
L
Ludovic Courtès wrote on 22 Oct 2017 21:03
(name . Dave Love)(address . dave.love@manchester.ac.uk)
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’.
T
T
Thomas Danckaert wrote on 24 Oct 2017 15:28
(address . ludo@gnu.org)
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
L
L
Ludovic Courtès wrote on 24 Oct 2017 17:30
(name . Thomas Danckaert)(address . post@thomasdanckaert.be)
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’.
R
R
Ricardo Wurmus wrote on 4 Dec 2017 00:07
(name . Thomas Danckaert)(address . post@thomasdanckaert.be)
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
T
T
Thomas Danckaert wrote on 4 Dec 2017 09:19
(address . rekado@elephly.net)
20171204.091953.594379672344347781.post@thomasdanckaert.be
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

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
C
C
Christopher Baines wrote on 19 Mar 2018 09:02
control message for bug #28690
(address . control@debbugs.gnu.org)
87vads5w8i.fsf@cbaines.net
tags 28690 patch
Z
Z
zimoun wrote on 13 Jan 2022 16:45
Re: bug#28690: provide a lib output for boost
(address . 28690@debbugs.gnu.org)
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.




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
Z
Z
zimoun wrote on 3 Feb 2022 03:30
(address . 28690@debbugs.gnu.org)
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
Z
Z
zimoun wrote on 23 Jun 2022 12:01
(address . 28690@debbugs.gnu.org)
86letn7l6r.fsf_-_@gmail.com
Hi,

On Thu, 03 Feb 2022 at 03:30, zimoun <zimon.toutoune@gmail.com> wrote:
Toggle quote (12 lines)
> 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>

[...]

Toggle quote (4 lines)
> 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
P
(name . zimoun)(address . zimon.toutoune@gmail.com)
52e71316834b3ca6d81cc4ddbbb709d3@thomasdanckaert.be
On 2022-06-23 12:01, zimoun wrote:
Toggle quote (27 lines)
> 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
Z
Z
zimoun wrote on 8 Oct 2022 17:06
(address . post@thomasdanckaert.be)
86edvis6b9.fsf_-_@gmail.com
Hi,

On Thu, 23 Jun 2022 at 13:35, post@thomasdanckaert.be wrote:
Toggle quote (22 lines)
> 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.

Toggle quote (3 lines)
> 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
Closed
?