guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#28690] provide a lib output for boost


From: Ludovic Courtès
Subject: [bug#28690] provide a lib output for boost
Date: Fri, 20 Oct 2017 14:58:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Hi Dave,

Dave Love <address@hidden> skribis:

> Roel Janssen <address@hidden> 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’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]