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