From: Chris Brannon <firstname.lastname@example.org>
Subject: Re: [edbrowse-dev] quick js
Date: Sun, 07 Mar 2021 08:15:31 -0800 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <firstname.lastname@example.org> (Karl Dahlke's message of "Sun, 07 Mar 2021 08:26:10 -0500")
Karl Dahlke <email@example.com> writes:
> * I'd like to make quick part of the official edbrowse, as of version 3.8.0.
> so it's hard to see why we shouldn't make the leap as soon as possible.
I don't see a reason not to ship it as soon as the core dumps and other
kinks are worked out, especially if it is going to be such a huge improvement.
> * Then there is the makefile, and not sure why we have two, or if we need two.
> Can't the makefile work for everybody, and forget GNUmakefile?
It should be possible to write a portable makefile. I'll work on that,
since I do have experience with build systems. On the topic of build
systems, would it be worth removing the cmake support?
> * quick builds a static library, not a shared library - does this
> present issues for our distributors?
Distros can package static libraries just as easy as dynamic libraries.
The advantage of a dynamic library for a distro maintainer is that if a
bug -- such as a security issue -- is found in a dependency, all of the
things that depend on it can be fixed by rebuilding the dynamic library.
With static linking, every package that links against the library needs
a rebuild. There's a minor shitstorm on the Internet right now about
this, because some newer programming languages (namely Rust and Go) tend
to favor static linking or even make dynamic linking impossible. My
advice is don't worry about it.
Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/).
Personal website: (https://the-brannons.com/)
Chat: IRC: teiresias on freenode, XMPP: firstname.lastname@example.org
next prev parent reply other threads:[~2021-03-07 16:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-07 13:26 Karl Dahlke
2021-03-07 16:15 ` Chris Brannon [this message]
2021-03-07 16:44 ` Karl Dahlke
2021-03-07 17:15 ` Chris Brannon
2021-03-07 18:40 ` Geoff McLane
2021-03-07 19:27 ` Karl Dahlke
2021-03-07 19:37 ` Chris Brannon
2021-03-08 8:46 ` Karl Dahlke
2021-03-08 19:31 ` Geoff McLane
2021-03-08 21:18 ` Karl Dahlke
2021-03-09 10:23 ` Kevin Carhart
2021-03-09 14:37 ` Geoff McLane
2021-03-09 22:52 ` Kevin Carhart
[not found] ` <email@example.com>
2021-03-14 20:36 ` Geoff McLane
2021-03-15 9:44 ` Kevin Carhart
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).