Re: [edbrowse-dev] Threads (fwd)

[Geoff McLane <ubuntu@geoffair.info>]

Hi Karl, Kevin,

Re: .ebrc: certfile = /etc/ssl/certs/ComSign_CA.pem curl errors
===============================================================

Just commented out that line, and everything worked fine... at
least in my little tests... thanks...

And I have had the SSL problems you sort of describe Kevin, particularly
in the Windows build. When building curl, from source, you have to
take care that it finds your build and install of SSL, plus OTHER
things... or else you get a very broken library... but that's another 
topic...

But generally, in linux, I usually depend that is is already installed,
or is available thru the package manager, or apt, or ... and try to
NEVER get into building from source, and installing, especially a system
wide install...

Trying $ curl https://weloveanimals.me

looks like it runs fine... in both ubuntu, and windows... so I think
I am good on the 'curl' front... thanks for the inputs...

Re: CMakeLists.txt changes - 2
==============================

Yes, I have mentioned TWO (2), separate, CMakeLists.txt changes - one for
Windows, and one for Unix...

The change for Windows is only to get rid of a warning, since I upgraded
my pthreads w32 installation... NOT important, and yes, could be included
in a PR, if/when I get that far...

But the change for Unix is critical to get the cmake build to work there...
patch given in previous... This suggests other linux/unix people
are `NOT` using 'cmake'! Or they would be shouting EEEEEK!...

On reading the README, I can see your continue to support, and obviously
use, of the src/makefile, or something... to me that is sad... maintaining
TWO (2), or 3?, separate, build systems is always tricky...

And the only way to maintain cmake, which is supposed to be for ALL
systems, is to use it, play with modifying it, get to understand, and
above ALL, trust that it will do the right thing... in ALL cases... make
it the /ONLY/ build option...

Karl, you are obviously maintaining the src/makefiles... and recently
must have added '-lpthreads'... this has to be also done in 
CMakeLists.txt...
just a few line of cmake script, as per my diff, and done...

I await your decision on which way to jump on this ;=))

Re: ftruncate/truncate WIN32 replacements - w32
===============================================

For testing, I have used a compile time #ifdef DOSLIKE, but when, if,
these w32 replacements work fine, then I would probably add something
like a win32/wtrunc.c src file, like dirent.c and vsprtf.c... so the ugly
#ifdef's can be removed from the main code...

But at the same time, would like you to have a look at my forks,
pthreads-w32 branch, and really ask is there not another way to
do this... in a more portable way...

Like not using ftruncate/truncate... maybe close and delete... or other
ways... but maybe not...

So I will try to get around to my very quick, kludgy, ugly, 
replacements... at
least to try and determine for sure that equivalence has been
achieved... soonest...

Re: create(), open(), - possible invalid pmode parameters - w32
===============================================================

Will also try to get to the latest pull... and try retesting
some of the open() changes... thanks for these...

Re: sorry about mixed topics in 1 email
=======================================

I can see you prefer separation... but I prepare all my
replies in an editor, like gedit, offline, so to speak... so
I like one file, like this ~/Documents/edbrowse/ebd-25-threads.txt,
covering ALL the latest I have received, at the time of
dispatch...

I suppose I could try dispatching it topic by topic... but
so could you split it up on receipt, separate on 'Re:', and
reply to each separately... that is also ok by me...
no probs...

Regards, Geoff.