jinja2cpp/Jinja2Cpp

How to link against std libs?

vyivanov opened this issue · 9 comments

vyivanov commented

From project readme:

Build with C++17 standard enabled
Jinja2C++ try to use standard versions of std::variant, std::string_view and std::optional if possible.

I tried to set JINJA2CPP_CXX_STANDARD=17, but it does not work. How to switch cmake build system to link against std libs?

rmorozov commented

@vyivanov,
Could you also please tell me about OS, compiler you are using?

vyivanov commented
  • linux 5.8.0-59-generic x86_64
  • g++ 9.3.0
rmorozov commented

I've bumped versions of 3rd party in master, would you mind rebasing and trying again?

vyivanov commented 
$ cmake .. -DJINJA2CPP_DEPS_MODE=external -DJINJA2CPP_CXX_STANDARD=17             
. . .
-- Jinja2Cpp C++ standard: 17
. . .
-- Could NOT find expected-lite (missing: expected-lite_INCLUDE_DIR) 
CMake Error at thirdparty/thirdparty-external.cmake:33 (message):
  expected-lite not found!
. . .

I've updated up to 171b5bd and see that cmake does request of external-lite which is std::external replacement. But std::external is just proposal and is not in standard yet. In order to get external-lite I need to use internal mode and eventually link against nonstd libs.

Do you have plans to get rid of external-lite dep?

rmorozov commented

std::expected have been accepted into 2023 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2400r1.html#expected

Maybe we will switch to some other more popular implementation of expected, but it seems what expected is one of the good ways of dealing with error-handling problems in modern C++ project

Do you want to get rid of of dependency that you need to provide manually or want problem do you want to solve?

If you use internal deps mode and compile with -DJINJA2CPP_CXX_STANDARD=17 nonstd::variant will be used as alias of std::variant, nonstd::optional -> std::optional, nonstd::expected - is implementation of expected.

I've checked resulting binaries and in c++17 mode there no symbols of nonstd::variant, but std::variant is used.

vyivanov commented

std::expected have been accepted into 2023

sounds good if it will be true and will be supported by compilers

want problem do you want to solve?

i just want the Jinja2Cpp do link against std libs as much as it could be

If you use internal deps mode and compile with -DJINJA2CPP_CXX_STANDARD=17 nonstd::variant will be used as alias of std::variant, nonstd::optional -> std::optional, nonstd::expected - is implementation of expected.

cool, i tried that, but got config errors on clean container: https://pastebin.com/30Zv2zDa

this is due to submodules in your project, shouldn't readme be updated with correct clone cmd to save guys time?

$ git clone --recursive https://github.com/jinja2cpp/Jinja2Cpp.git

instead of

$ git clone https://github.com/flexferrum/Jinja2Cpp.git
vyivanov commented

I've checked resulting binaries and in c++17 mode there no symbols of nonstd::variant, but std::variant is used.

yep, that's true: i also got the same results:

  • nonstd::expected_lite
  • std::optional
  • std::variant
  • std::basic_string_view

cool, thanks for support!

  • 😄1
rmorozov commented

it seems that I've fixed cloning issue in 15a5f76

It should be working with simple

git clone

rmorozov commented

I've checked resulting binaries and in c++17 mode there no symbols of nonstd::variant, but std::variant is used.

yep, that's true: i also got the same results:

  • nonstd::expected_lite
  • std::optional
  • std::variant
  • std::basic_string_view

cool, thanks for support!

You are welcome!