New release timeline about liblifthttp

[ncoder-1]

Correct, no other changes needed. It's mainly for user convenience really. Everyone's got their own way of importing external projects, just figured I'd point out one option using FetchContent.

[ncoder-1]

Awesome! I'll port my stuff to your library, let it run its tests and see how that works out and let you know. Thanks again!

[jbaldwin]

Hey, thanks for reaching out. This feels like a good time to publish a new v3 version + tag. There have been quite a few cleanup/api refinements to try and make it more consistent moving forward as well as making the regression tests more robust. I've got a few more cmake changes I'd like to roll into this but then I can publish v3, would tomorrow work for you?

[ncoder-1]

Of course, no rush, good work by the way! Speaking of cmake, I'd propose that if you are using cmake ≥ 3.11, you can use the following to add your project at the configuration time instead of build time, which would allow some IDE (such as QT Creator) to properly find the headers and functions for syntax checking:

cmake_minimum_required(VERSION 3.11)

# stuff

include(FetchContent)
FetchContent_Declare(
  lifthttp
  GIT_REPOSITORY https://github.com/jbaldwin/liblifthttp.git
  GIT_TAG        v2.0
)
FetchContent_MakeAvailable(lifthttp)

# other stuff

target_link_libraries(${PROJECT_NAME} PRIVATE lifthttp)

This is where the release matters (in my case at least) because it will pull whatever version you are specifying (mainly for reproducible builds).

[jbaldwin]

Would this need to be declared for each tag version? I'm not familiar with how FetchContent works but it looks really cool.
Edit:
I think I understand now, this is how you are including it in your project, so you would declare the tag/version you wanted for a reproducible build, very similar to how git submodules work.

[ncoder-1]

Exactly like git submodules (this explains it properly), you don't have to include a git tag, in which case it will fetch master. It's slightly better if you do put a release tag so you don't encounter api breaking issues by always pulling the latest master.

[jbaldwin]

I don't mind setting the required verison to 3.11 in the lift cmakelists.txt, 2.8 is quite ancient, but unless if I'm misunderstanding this I don't think any other change are required for lift?

[jbaldwin]

Ubuntu 18.04 appears to only have cmake 3.10 so I'll see if we can build 3.11 from source in the regression pipeline.

[ncoder-1]

Not very surprised that Ubuntu has such an old version of cmake. 3.11 was released March 2018... Arch FTW.

Edit: Maybe don't modify your CMakeLists.txtbut mention the option in the README.md file?

[jbaldwin]

https://github.com/jbaldwin/liblifthttp/pull/67/files

How about this for the readme? Seems like a good alternative, compiling cmake is too expensive for a regression run and I'd rather not bake it into a docker container if I can avoid it.

[ncoder-1]

Yep that's perfect!

[jbaldwin]

https://github.com/jbaldwin/liblifthttp/releases/tag/v3.0

Give it a whirl when you get a chance and let me know if you run into any issues.

[ncoder-1]

Will do, I'll give an update tomorrow! Thanks!

[ncoder-1]

Only issue I'm seeing right now is:
std::cout << "HTTP Status Code: " << lift::to_string(response.StatusCode()) << "\n";
gives:

error: cannot initialize a parameter of type 'lift::LiftStatus' with an rvalue of type 'http::StatusCode'
LiftStatus.hpp:49:16: note: passing argument to parameter 'status' here

[jbaldwin]

What compiler and version are you using?
edit: It appears to be using the wrong to_string function, is this in a specific example? I have had all the errors/warnings turned down for a while, maybe I should bump that back up

[ncoder-1]

Yep, directly from the README.md. I'm using clang 9.0.1 and also gcc 9.3.0.

[jbaldwin]

let me try the readmes again manually, I copied them directly from the examples/ directory but maybe they are out of date again, whoops

[jbaldwin]

ok yep, totes broken, I'm going to add a readme.cpp example which is literally the readme code so its always compiling, i'll make a 3.1 for you in a minute

[ncoder-1]

lol thanks!

[jbaldwin]

https://github.com/jbaldwin/liblifthttp/releases/tag/v3.1
Should be good in the README now, there is also an examples/readme.cpp that is identical code.

[ncoder-1]

Works great! Only issue I encountered is my code would check the status code from curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, &response_code) which is actually a long according to https://github.com/curl/curl/blob/master/include/curl/curl.h, so it's easy to compute if it's a 200 or 404 for example, instead of doing a string compare against "200 OK". I'm going to do some benchmarking to see if there's a noticeable loss in performance or if its negligible. Thanks again!

Edit: Feel free to close this issue. I'll open up a new one if needed.

[jbaldwin]

Maybe the following would be better? This will do a direct integer compare like the CURLINFO_RESPONSE_CODE but with a c++ enum class for static typing. Hope that helps.

if(response.StatusCode() == lift::http::StatusCode::HTTP_200_OK) { ... do something .. }

[ncoder-1]

Yeah that works great actually, thanks!