edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Karl Dahlke <eklhad@comcast.net>
To: edbrowse-dev@edbrowse.org
Subject: [edbrowse-dev] quick js
Date: Sun, 07 Mar 2021 14:27:17 -0500	[thread overview]
Message-ID: <20210207142717.eklhad@comcast.net> (raw)
In-Reply-To: <602cf413-c280-6582-45b8-3a071172301c@geoffair.info>

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

Geoff: thank you for your kind and thoughtful reply.
You have been such a big help to us over the years.
I'm glad you still monitor this list.

I've come to realize over the years that a makefile, even if it's linux only, is valuable to us, because of the many other targets we build,
targets that will never be used by the casual user or the distributor.
So it's ok if these targets only build on linux.
Example: all those hello world programs that let us play with the various javascript engines.
So nice to just type make hello
And other targets to build debugging modes into edbrowse.
So we may well keep cmake going, but I think we will always have our own makefile in addition to cmake, even if it first seems a bit redundent.

I didn't want to ask you to restructure anything - until we were sure of our direction.
I think we're coming to a concensus.
I'll let you know.

As per the big question of do we even support windows and/or cmake any more, I don't know.
We all put a lot of work into it; yet there seems to be not a single windows edbrowse user.
It's just more compatible with the nix systems and the way they function.
Tyler has explained it more eloquently than I could.

One of my thoughts was, it might be easier to get funding if we could claim it ran on every platform, including windows.
Organizations expect that.
But we've never gotten a dime of funding anyways, so idk.
Meantime it is a bit of overhead to keep the windows port up.
All thoughts are welcome.

Meantime, you could casually ask yourself, in the background, what would have to change if duktape were replaced with quick.
Is it hard to do, or is it a quick fix?     Ha ha ha!
(I couldn't resist that one.)

Karl Dahlke

  reply	other threads:[~2021-03-07 19:27 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
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 [this message]
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]                   ` <20210210053836.eklhad@comcast.net>
2021-03-14 20:36                     ` Geoff McLane
2021-03-15  9:44                       ` Kevin Carhart

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210207142717.eklhad@comcast.net \
    --to=eklhad@comcast.net \
    --cc=edbrowse-dev@edbrowse.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).