edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Geoff McLane <ubuntu@geoffair.info>
To: Chris Brannon <chris@the-brannons.com>,
	edbrowse-dev@edbrowse.org, Karl Dahlke <eklhad@comcast.net>
Subject: Re: [edbrowse-dev] quick js
Date: Sun, 7 Mar 2021 19:40:36 +0100	[thread overview]
Message-ID: <602cf413-c280-6582-45b8-3a071172301c@geoffair.info> (raw)
In-Reply-To: <87a6rej35p.fsf@the-brannons.com>

Hi Karl, Chris, et al,

Wow, you touch on so many things, hard to know what to answer...

cmake vs makefile:

Any 'makefile' is basically unix/linux, *nix, only... There is really no 
such thing as a portable makefile, at least as far as Windows is 
concerned. Yes, MSVC Windows has `nmake`, but it deviates from most *nix 
makes, often very significantly...

cmake, on the other hand, is a `makefile` generator, and includes a 
'configure' stage, before the 'generator' kicks in, so is suitable for 
windows, and *nix, mostly... and is the closest we have to 'portable'...

I recently built edbrowse in windows, and pushed a 'win32' branch, with 
most of the required changes, but with Karl's faster than light changes, 
became outdated even before it landed... but no problem... keep up the 
energy Karl... ;=))

static vs shared: Yes, this is a storm!

*nix has a very good system in places to deal with 'shared' - just a few 
'fixed' directories - and their many arguments in favor of this are very 
sound...

Windows is a big problem case - no 'fixed' directories - or rather the 
ones there are like C:\Windows, etc... are really only for true 'system' 
software... certainly NOT recommended for other, 3rdParty, software...

Yes, others can be added to the PATH, by an 'installer', which has to 
have 'admin' privileges, and must include all/most shared DLLs, but then 
you get a horrendous PATH variable. Already, in my relatively new DELL03 
machine it is over 1300 bytes long, some 36 paths... and continues to 
grow... on just about every 3rdparty install...

AND can lead to conflicts, breaks, as happened recently with a 
'Strawberry' perl install... It put some things in the PATH which broke 
several other 3rdPary builds... and was hard to find, debug...

And yes, I had this big fight with other *nix distro maintainer, about 
what I do with 'Tidy'... and compromised on adding cmake options to 
allow them to build/install tidy 'their' way ;=)) while still keeping my 
convenient Windows way...

Windows support:

Windows will always be a problem, especially edbrowse dependence on 
3rdParty libs... it requires considerable understanding and effort... to 
setup...

So, simply, some of this discussion would just go away, if you drop 
Windows support, and thus drop cmake!

This might not be a problem, since at this time, I do not think there is 
any other edbrowse users in Windows... they would be yelling otherwise - 
can't build edbrowse, for lots of reasons...

Good luck, with what ever you decide... will continue to help where I can...

HTH!

Best regards,
Geoff.



  reply	other threads:[~2021-03-07 18:41 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 [this message]
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]                   ` <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=602cf413-c280-6582-45b8-3a071172301c@geoffair.info \
    --to=ubuntu@geoffair.info \
    --cc=chris@the-brannons.com \
    --cc=edbrowse-dev@edbrowse.org \
    --cc=eklhad@comcast.net \
    /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).