Hi Ludo’,

Switched to build as shared libraries, and bumped versions.

Greg

On Mon, Mar 8, 2021 at 8:49 AM Ludovic Courtès <ludo@gnu.org> wrote:

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