Re: time to remove Visual Studio project files?

[Ray Satiro via curl-library]

On 9/5/2020 9:16 AM, Daniel Stenberg via curl-library wrote:


I'd like to get a better feel for the need to ship the visual studio 
project files we currently host in the project/ directory.


Do you use them? Why isn't generating these files using cmake good 
enough?


If we're going to keep them, I'd like to do some cleanups (like 
renaming the rather strange directory name) and add more documentation 
for them. That requires that there are users of these files that are 
prepared to work (with me) on that. 



I use the Visual Studio project files. I like that there's several 
configurations that I can switch between. Changing the directory name 
will make it difficult for me to go back and forth between commits.


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Connecting to IMAP server using libcurl

[Daniel Stenberg via curl-library]

On Tue, 1 Sep 2020, Jeffrey McKay via curl-library wrote:

In my program, I can connect to my test server (outlook.office365.com), and 
if I use port 143, the insecure IMAP port, I can receive the response. But 
if I use secure port 993, the program hangs on the select() command, timing 
out after 60 seconds.


If you want TLS already in the connect procedure, you need to use a URL that 
says so. Your code:


strcpy_s(imap_host, "outlook.office365.com");
curl_easy_setopt(curl, CURLOPT_URL, imap_host);

... uses no protocol scheme at all which will make curl guess, and in this 
case it thinks it is "http" - in clear text. It won't try to do any TLS 
negotiation on a clear text connection.


--

 / daniel.haxx.se | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: time to remove Visual Studio project files?

[Rod Widdowson via curl-library]

> On 5 Sep 2020, at 17:13, Joel Winarske via curl-library 
>  wrote:
> 
> I would say if the two were brought to parity then you could drop the nmake 
> files.

That’s a pretty big if.  There are a lot of things at the edge of the NMAKE 
build which might be problematic.  I’m away from my sources right now so I 
cannot give exact details..

> I can take a look later next week.

If you get a PR put together can you either FU here (or reach out to me 
directly) and I’ll give it a spin against our somewhat ‘edge’ build? I don’t 
have the cycles any more to follow the curl github stream directly.

Thanks ,

Rod

---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: time to remove Visual Studio project files?

[Josh Handley via curl-library]

We currently use the nmake files directly without CMake. Would be fine to drop 
the visual studio project files but please keep the the nmake files. Not 
everyone wants to introduce CMake into their build process.

> On Sep 5, 2020, at 12:03 PM, Joel Winarske via curl-library 
>  wrote:
> 
> I would say if the two were brought to parity then you could drop the nmake 
> files.  I can take a look later next week.
> 
> On Sat, Sep 5, 2020, 8:57 AM Daniel Stenberg  > wrote:
> On Sat, 5 Sep 2020, Joel Winarske wrote:
> 
> > To clarify you can generate nmake files with CMake.
> 
> Aha! Then I suppose a question is how those files differ compared to those we 
> ship.
> 
> -- 
> 
>   / daniel.haxx.se  | Commercial curl support up to 
> 24x7 is available!
>| Private help, bug fixes, support, ports, new features
>| https://www.wolfssl.com/contact/ 
> 
> ---
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette:   https://curl.haxx.se/mail/etiquette.html

---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: time to remove Visual Studio project files?

[Joel Winarske via curl-library]

I would say if the two were brought to parity then you could drop the nmake
files.  I can take a look later next week.

On Sat, Sep 5, 2020, 8:57 AM Daniel Stenberg  wrote:

> On Sat, 5 Sep 2020, Joel Winarske wrote:
>
> > To clarify you can generate nmake files with CMake.
>
> Aha! Then I suppose a question is how those files differ compared to those
> we
> ship.
>
> --
>
>   / daniel.haxx.se | Commercial curl support up to 24x7 is available!
>| Private help, bug fixes, support, ports, new features
>| https://www.wolfssl.com/contact/
>
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: time to remove Visual Studio project files?

[Daniel Stenberg via curl-library]

On Sat, 5 Sep 2020, Joel Winarske wrote:


To clarify you can generate nmake files with CMake.


Aha! Then I suppose a question is how those files differ compared to those we 
ship.


--

 / daniel.haxx.se | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: time to remove Visual Studio project files?

[Joel Winarske via curl-library]

To clarify you can generate nmake files with CMake.

On Sat, Sep 5, 2020, 8:35 AM Daniel Stenberg via curl-library <
curl-library@cool.haxx.se> wrote:

> On Sat, 5 Sep 2020, Rod Widdowson via curl-library wrote:
>
> > I'd be *very* reluctant to see the NMAKE files go, but we have never
> used
> > the vcxproj files.  As I recall, I couldn't get over the apparent
> impedance
> > mismatch between the multiple parameterization options and the
> configuration
> > types.
>
> Thanks, but I have no intentions of removing the nnake files. I believe
> those
> are in a rather good shape, are frequently used and the documentation for
> them
> is decent. They are makefiles, easy to understand and maintain even for us
> who
> don't actually ever use them.
>
> I was hoping that building curl on windows could be narrowed down to
> primarily
> be using these:
>
>   - nmake for building with visual studio (winbuild/)
>   - configure for msys/mingw style builds
>   - cmake for the rest
>   - (mingw makefiles for the adventureous, but they remain mostly
> undocumented)
>
> The VS project files are different. They are custom XML files for a
> proprietary product that are (next to) impossible for anyone without that
> tool
> to verify and fix. And cmake can generate such files.
>
> --
>
>   / daniel.haxx.se | Commercial curl support up to 24x7 is available!
>| Private help, bug fixes, support, ports, new features
>| https://www.wolfssl.com/contact/
> ---
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette:   https://curl.haxx.se/mail/etiquette.html
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

RE: time to remove Visual Studio project files?

[Daniel Stenberg via curl-library]

On Sat, 5 Sep 2020, Rod Widdowson via curl-library wrote:

I'd be *very* reluctant to see the NMAKE files go, but we have never used 
the vcxproj files.  As I recall, I couldn't get over the apparent impedance 
mismatch between the multiple parameterization options and the configuration 
types.


Thanks, but I have no intentions of removing the nnake files. I believe those 
are in a rather good shape, are frequently used and the documentation for them 
is decent. They are makefiles, easy to understand and maintain even for us who 
don't actually ever use them.


I was hoping that building curl on windows could be narrowed down to primarily 
be using these:


 - nmake for building with visual studio (winbuild/)
 - configure for msys/mingw style builds
 - cmake for the rest
 - (mingw makefiles for the adventureous, but they remain mostly undocumented)

The VS project files are different. They are custom XML files for a 
proprietary product that are (next to) impossible for anyone without that tool 
to verify and fix. And cmake can generate such files.


--

 / daniel.haxx.se | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

RE: time to remove Visual Studio project files?

[Rod Widdowson via curl-library]

> Do you use them? Why isn't generating these files using cmake good enough?

I appreciate that this doesn't fully answer your question but

I'd be *very* reluctant to see the NMAKE files go, but we have never used the 
vcxproj files.  As I recall, I couldn't get over the apparent impedance 
mismatch between the multiple parameterization options and the configuration 
types.

If you go for a cleanup (or some CMAKE work) I would urge you to consider using 
the /MP (multi-processor) option.  File by file compilation looks very 
pedestrian these days (although the time taken to do the OpenSSL file-by-file 
compile pretty much swamps everything).

So I guess my answer is "No", "Dunno".

Rod




---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: The strange connect behavior of curl via socks5 proexy to different websites.

[Daniel Stenberg via curl-library]

On Sat, 5 Sep 2020, Hongyi Zhao wrote:

Is there really *anything* that implies that this is curl's fault and not 
just something in Tor or even in the target server that just don't like 
incoming traffic from Tor?


Any hints for debug/confirm this problem?


In general I would say that if curl works fine against most servers and fails 
against a subset/single server, chances are very high that the problem is that 
particular server.


Of course to figure this out *for sure* I suppose you'd need to investigate 
exactly what's sent and received over the wire and why. Not terribly easy.


--

 / daniel.haxx.se | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Obtain Response String From a CURL Handle for SMTP Connections

[Daniel Stenberg via curl-library]

On Fri, 4 Sep 2020, RE lesgoe via curl-library wrote:


I suggest a new CURLINFO value, CURLINFO_RESPONSE_STRING


...

Currently, the only way to obtain the full response string is by enabling 
CURLOPT_VERBOSE and CURLOPT_DEBUGFUNCTION, which is overkill for this 
situation.


Sounds like a reasonable feature to me.

We put ideas to work on in the future in the TODO document. We basically drown 
in good ideas. Ideas are easy, getting them actually implemented is harder.


If you really want to see this happen, start working on an implementation and 
submit a PR for it or try to talk up more interest for it and see what help 
from others you can get!


--

 / daniel.haxx.se | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

time to remove Visual Studio project files?

[Daniel Stenberg via curl-library]

Hi,

I'd like to get a better feel for the need to ship the visual studio project 
files we currently host in the project/ directory.


Do you use them? Why isn't generating these files using cmake good enough?

If we're going to keep them, I'd like to do some cleanups (like renaming the 
rather strange directory name) and add more documentation for them. That 
requires that there are users of these files that are prepared to work (with 
me) on that.


--

 / daniel.haxx.se | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
  | https://www.wolfssl.com/contact/
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html