Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Nov 2020 19:44:13 -0800
From:      Kevin Oberman <rkoberman@gmail.com>
To:        bugzilla-noreply@freebsd.org
Cc:        FreeBSD GNOME Users <gnome@freebsd.org>
Subject:   Re: [Bug 251014] x11-wm/openbox Prefer graphics/ligvrsvg2-rust over graphics/librsvg2
Message-ID:  <CAN6yY1uu7ibUwqn-G_SbyqfuEbvefD5cdS3iqdYB1=RW5XbpNw@mail.gmail.com>
In-Reply-To: <bug-251014-6497-qFEYFmqoR1@https.bugs.freebsd.org/bugzilla/>
References:  <bug-251014-6497@https.bugs.freebsd.org/bugzilla/> <bug-251014-6497-qFEYFmqoR1@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 11, 2020 at 6:18 PM <bugzilla-noreply@freebsd.org> wrote:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251014
>
> Alexey Dokuchaev <danfe@FreeBSD.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |danfe@FreeBSD.org
>
> --- Comment #5 from Alexey Dokuchaev <danfe@FreeBSD.org> ---
> (In reply to p5B2E9A8F from comment #0)
> > please make graphics/librsvg2 a port option choice
> Technically it is optional in Openbox, albeit enabled by default.  The
> problem
> is more serious for ports where librsvg2 is not an optional dependency, and
> thus cannot be easily turned off.
>
> With this patch and DEFAULT_VERSIONS+=librsvg2=legacy, I can finally build
> Openbox again with default options, thank you Tobias.  Prior to this
> change it
> was impossible because apparently this Lenovo L470 laptop of mine with 8GB
> RAM
> is not potent enough.
>
> > I could lash out for a nice rant but I'm not going to do that.
> I'll just say that may it be an example of why one should *not* try to
> rewrite
> popular open-source C library (which can be compiled even on, I don't know,
> TI-85?) in a "better" tongue that requires 100500 GB of RAM just to build
> itself, not to mention it being self-hosted and thus requiring bootstrap on
> every architecture.  This could be tolerable for leaf ports, but really
> horrible for maintaining reusable open-source components serving as
> dependencies for vast variety of software.


First, I suggest installing rust as a package rather than building locally.
I usually do build locally, but it's not really necessary. Mixing ports and
packages can be tricky, but things like llvm, gcc, and rust should not be
an issue.

Second, I have no problem building rust on my older/slower T520. (Same as a
T420 except a 15 inch screen.) I do need to "setenv TMPDIR
/some/place/with/>1G/space unless I have /tmp with access to a big chunk of
storage and am not using tmpfs. The rust build also requires serious swap
space (hence, not tmpfs) but I use 16GB of swap and it does not come close
to running out. I suspect 8GB would be adequate. Then start it building
when I won't need much from the system for about 4 hours.

I think it likely that more open source projects will move to rust. I am
not a real coder any longer and my best days as a programmer were mostly
writing machine language long before C took over when kernels were written
in macro, but I find it significantly superior to C in many respects,
especially in writing secure code that does not leak memory all over the
place. I suspect that rust will be simply a basic requirement for most
systems that build software from source in three or four years. That said,
I didn't give python much chance to really catch on back in v1 days or even
in the early days of v2, so I can't claim to be a great prognosticator.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1uu7ibUwqn-G_SbyqfuEbvefD5cdS3iqdYB1=RW5XbpNw>