editors/vim needs devel/llvm90 and devel/llvm10

[Adam Weinberger]

On Mon, Nov 30, 2020 at 3:28 PM Matthias Apitz <guru at unixarea.de> wrote:
>
>
> Hello,
>
> I'm building ports on HEAD of today and I see that editors/vim pulls in
> devel/llvm10 and devel/llvm90:
>
> [freebsd-r368166-ports-20201130] [2020-11-30_23h11m34s] [parallel_build:] Queued: 63 Built: 15 Failed: 0  Skipped: 0  Ignored: 0  Tobuild: 48  Time: 00:04:57
>         [01]: x11/libXxf86vm            | libXxf86vm-1.1.4_3        configure       (00:00:08 / 00:00:13)
>         [02]: devel/llvm90              | llvm90-9.0.1_3            build           (00:00:09 / 00:02:39)
>         [03]: devel/llvm10              | llvm10-10.0.1_3           build           (00:00:03 / 00:04:09)
>         [04]: x11/libXrandr             | libXrandr-1.5.2           configure       (00:00:08 / 00:00:14)
>
> Why is this?
>
>         matthias

Jan's answer is completely correct about why both get pulled in and
that it's possible to avoid concurrent llvms by setting
DEFAULT_VERSIONS.

The default vim setup involves the gtk3 frontend. The list of gtk3
requirements is growing without bounds at this point, to the point
that I can't even test built vim with its default frontend (it's well
over 14 hours of build time just to build the dependencies).

While the end-user package burden is significantly lower, I suspect
very, very few users actually make use of the gtk3 frontend-specific
features. Honestly, the plain x11 frontend is probably sufficient for
the vast majority of gvim users (it's what I test with), and if you
don't use GUI vim at all then I strongly encourage the vim-console
package (or vim with the CONSOLE option enabled).

GVim being all things to all people made sense when the build time
barely differed, but this is no longer the case. If I could make vim
just be the console package and vim-gtk3 be just the gvim binary, I
would. Unfortunately, the vim binary itself links with the frontend
toolkit.

Of course, there's nothing in this rant that answers your question at
all, Matthias.

# Adam


-- 
Adam Weinberger
adamw at adamw.org
https://www.adamw.org