[bug#46728] [PATCH 0/7] gnu: aws-sdk-cpp: Update to 1.8.148.

[Ludovic Courtès]

Hi Greg,

Greg Hogan <code@greghogan.com> skribis:

> On Tue, Mar 2, 2021 at 2:37 PM Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> In general, it’s best to build only shared libraries.  That allows for
>> reduced memory usage, fast security updates via grafts, etc.  So if you
>> could make the AWS packages build as shared libraries only, that’d be
>> great.
>>
>> It’s OK to optionally add static libraries, preferably in a separate
>> output or even a separate package, but that’s not what should be used by
>> default.
>>
>> Does that make sense?
>
>
> Yes, I would prefer to provide shared as the default output and static as a
> separate output to the same package.

One option is to not provide static libraries at all, at least for now.
They make little sense from a Guix perspective anyway.

Would that be an option for you?

> There look to be three options:
>
> 1) separate packages (as with boost and boost-static). This is simple but
> not as elegant (boost-static is the eighth most relevant package when guix
> search'ing for "boost").
>
> 2) duplicate CMake phases in the package definition (much more verbose than
> with gnu-build-system). This results in considerable duplication of build
> system code and is unmaintainable.

Can’t CMake build both static and “shared” (-fPIC) libraries in one go?
I think it can do that.

> 3) extend the cmake-build-system to optionally configure, build, and
> install static libraries with additional phases. The ideal result but
> requires modification of the cmake-build-system.

In the vast majority of cases, we don’t provide static libraries at
all.  The only exceptions are when we need statically linked binaries
for bootstrapping purposes or within the initrd.

HTH,
Ludo’.