From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12294 invoked from network); 7 Mar 2021 16:16:02 -0000 Received: from hurricane.the-brannons.com (2602:ff06:725:1:20::25) by inbox.vuxu.org with ESMTPUTF8; 7 Mar 2021 16:16:02 -0000 Received: from localhost.localdomain (localhost [127.0.0.1]) by hurricane.the-brannons.com (OpenSMTPD) with ESMTP id f038c6e7 for ; Sun, 7 Mar 2021 08:15:54 -0800 (PST) Received: from localhost ( [2602:3f:e0f9:dc00::2]) by hurricane.the-brannons.com (OpenSMTPD) with ESMTPSA id af221740 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Sun, 7 Mar 2021 08:15:32 -0800 (PST) From: Chris Brannon To: edbrowse-dev@edbrowse.org Subject: Re: [edbrowse-dev] quick js References: <20210207082610.eklhad@comcast.net> Date: Sun, 07 Mar 2021 08:15:31 -0800 In-Reply-To: <20210207082610.eklhad@comcast.net> (Karl Dahlke's message of "Sun, 07 Mar 2021 08:26:10 -0500") Message-ID: <87eegrhrdo.fsf@the-brannons.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List MIME-Version: 1.0 Content-Type: text/plain Karl Dahlke writes: > * I'd like to make quick part of the official edbrowse, as of version 3.8.0. *SNIP* > 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. -- Chris Brannon Founder: Blind and Low Vision Unix Users Group (https://blvuug.org/). Personal website: (https://the-brannons.com/) Chat: IRC: teiresias on freenode, XMPP: chris@chat.number89.net