From: Geoff McLane <firstname.lastname@example.org> To: Chris Brannon <email@example.com>, firstname.lastname@example.org, Karl Dahlke <email@example.com> Subject: Re: [edbrowse-dev] quick js Date: Sun, 7 Mar 2021 19:40:36 +0100 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.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.
next prev parent 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] ` <firstname.lastname@example.org> 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
edbrowse-dev - development list for edbrowse This inbox may be cloned and mirrored by anyone: git clone --mirror http://inbox.vuxu.org/edbrowse-dev # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 edbrowse-dev edbrowse-dev/ http://inbox.vuxu.org/edbrowse-dev \ firstname.lastname@example.org public-inbox-index edbrowse-dev Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.vuxu.org/vuxu.archive.edbrowse.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git