Conversation
|
Locally, I'm getting sign-compare errors in the lib, which we don't want to fix directly.
Is the |
|
https://stackoverflow.com/questions/3371127/use-isystem-instead-of-i-with-cmake but I'm not sure where we should apply it (ideally all externals use |
|
Update on 0.7.6 didn't solve the issue on my PC, test keeps failing. Note: I have to correct the signess in the for loop in the library header & comment client->set_timeout_sec(30); everywhere on our side since they changed this function |
thanks for reporting. sad it didn't resolve the issue. Do we want to go through updating our codebase to this anyway? |
|
Oh, I think I see it... Also line 432 for the MNIST and other places. We could catch all of them in one place by including SYSTEM at the beginning of the list at the point where the EXTERNAL_INCLUDES list is built which is line 93 of extern/bootstrap.cmake. If we do that, the SYSTEM at line 249 of src/CMakeLists.txt becomes redundant so that could be removed. I have not tried this but it should work. |
in target_include_dirs(xx SYSTEM yy) to avoid unrelated warnings in thirdparty projects.
somehow, did not suffice to use SYSTEM for external_includes; so using pragma ignored individually when including httplib.h
in the 3rd party lib, so avoid using it.
breznak
left a comment
There was a problem hiding this comment.
It now seems to be working with the new lib. Please see comments bellow and possibly approve.
| ${EXTERNAL_INCLUDES} | ||
| ${CORE_LIB_INCLUDES} | ||
| ${PROJECT_SOURCE_DIR} | ||
| SYSTEM ${PYTHON_INCLUDE_DIRS} |
There was a problem hiding this comment.
Thanks @dkeeney for the advice!,
We could catch all of them in one place by including SYSTEM at the beginning of the list at the point where the EXTERNAL_INCLUDES list is built which is line 93 of extern/bootstrap.cmake.
I tried this, by adding "SYSTEM" to the set(EXTERNAL_INCLUDES ...) but that didn't work as intended.
On line 450 and 464 of src/CMakeLists.txt, I did not specify SYSTEM for EXTERNAL_INCLUDES.
..so I fixed all ocurences of EXTERNAL_INCLUDES in target_include_dirs() with SYSTEM, that works.
But not for httplib, unfortunately. Is it included in the EXTERNAL_INCLUDES, or does it use a different means of including?
| #pragma GCC diagnostic push | ||
| // turn off the specific warning. Can also use "-Wall" | ||
| #pragma GCC diagnostic ignored "-Wsign-compare" | ||
| #include <httplib.h> |
There was a problem hiding this comment.
the SYSTEM include did not fix the warnings generated in httplib (I wonder why?), so I had to hack with #pragma here and in server_core.hpp.
There was a problem hiding this comment.
the SYSTEM include did not fix the warnings
I don't know of a way to get around the warnings other than with the #pragma.
| VERBOSE << "Connecting to server: " + serverHost + " port: " << port << std::endl; | ||
| httplib::Client client(serverHost.c_str(), port); | ||
| client.set_timeout_sec(30); // The time it waits for a network connection. | ||
| //client.set_timeout_sec(30); // The time it waits for a network connection. |
There was a problem hiding this comment.
@Zbysekz did you find out if there's a replacement for the httplib.set_timeout_sec(), or if we just stop using that function?
There was a problem hiding this comment.
We have an answer: set_connection_timeout() is the substitute.
@breznak this PR is closed maybe starting another? I am not sure about consequences, or what timeout is by default
There was a problem hiding this comment.
nice! sorry for merging early. Yes, we can start a new PR where you can revert commit 606cb75d00cb376 and then change it to the new signature.
I am not sure about consequences, or what timeout is by default
nor do i. our tests passed even without it. maybe in the server it makes sense, in the unit tests 30sec is imho too much.
The default web client timeout is 2 min (same as almost all web browsers). The call to set_timeout_sec( ) was an attempt to shorten the time the client takes to report that it cannot find the server. If the connection happens right away the timeout setting has no effect. I think we can safely remove the call to set the timeout. |
thank you for explanation David. So then I think no further action is needed and this can stay as is. |
hoping it might resolve issue in #783